【QBASIC互換!?】FreeBasic【GPL】 2 [無断転載禁止]©2ch.net (430ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
140(4): デフォルトの名無しさん [] 2017/05/09(火) 19:35:55.11 ID:YDoq9mLA(1) AAS
ファイル名関係処理でDBCS関連がらみの処理をどうしようか、
と迷っていたら、ファイル名関係のシステムコール(スーパーバイザ参照)ルーチンを見つけた。
細かいことは C:\tool\FreeBASIC\inc\win\shlwapi.BI を見てくれ。
「declare function Path」で検索すると、主要なルーチン名を見つけることができる。
一部 declare sub Pathなんたら()があるから注意してくれ。
「Pathなんたら()」と記載しないと参照できない。
141(2): デフォルトの名無しさん [] 2017/05/13(土) 22:52:55.55 ID:6qsyWLV0(1) AAS
外部ﾘﾝｸ[html]:www.dotup.org
外部ﾘﾝｸ[html]:www.dotup.org
>>140 関係。動作試験した内容。
使いたい人がいたら、適当に使って。
ネットワーク関係のシステムコールが見つかったので整理中。
ローカルでの運用が主体なので、MSネットワーク関係が出てきて混乱している。
V.B.を購入した2000年頃の内容では、MSネットワークがウイルスソフトにやられることが多いので、MSネットワークは使用しないように、というウイルス対応が多かった。
だから、関係ルーチンを使わないようにしていた。だから、内容が理解できない。
C:\tool\FreeBASIC\inc\win\shlwapi.bi の内容は検索してみればわかる通り、個人サイトでは2010年頃に公開されている。
だから、かなり出遅れた内容となる。
'' MS指示 PathAddExtension() → PathCchAddExtension() を使え
なんて旨の内容もある。MSが指定したルーチン名はC:\tool\FreeBASIC\以下の*.BIファイルには見つからなかった。
近い将来、サポートされるものと思う。
142: デフォルトの名無しさん [] 2017/05/14(日) 11:53:59.80 ID:J0U25/Ze(1) AAS
>>140 つづき。
Astring = "*.Txt": Kill Astring
がうまく動作しなくてはじめたこの処理だけど、こんなの見つけてしまった。
外部ﾘﾝｸ[html]:www.all.undo.jp
＞有用性の高いWindows APIの動作が変わってる事だと思います。
＞具体的にはPathMatchSpec()というAPIです。
＞このAPIはWindows 8正式版の頃から挙動が怪しくなりまして、取りこぼしやら誤ヒットやらと、落ちるわけじゃないんですが比較の結果が正しくない文字が多数発生してました。
ということで、>>141の内容で打ち切って、自前ルーチンの作成が必要であるということになってしまった。
＞Windows Vista以降であればPathMatchSpecEx()というAPIが別で存在している
PathMatchSpecEX()があるらしいのだが、FreeBasic ではサポートされていない。
＞FindFirst系のAPIだとワイルドカードの組み合わせによって
は、皆さんご存知ですよね。Win 95頃長いファイル名がサポートされて、別名として短いファイル名が用意された。
別名、つまり、8.3形式のファイル名では重複するときに末尾2文字以上を(チルダ)(数字)に置き換える。
だから、おかしなことになりやすい。*で拾って、個別に比較して、処理するということが必要になってくる。
末端ユーザー(オペレーター)に対して、チルダを使うな、と指示して、チルダを使っているファイルをユーザーレベル(プログラム仕様書)で排除すれば済むのだけれど。
143: デフォルトの名無しさん [] 2017/05/17(水) 20:43:36.59 ID:5N4X+pOX(1) AAS
>>141 のつづき。
外部ﾘﾝｸ[html]:www.dotup.org
外部ﾘﾝｸ[html]:www.dotup.org
>>140 関係。動作試験した内容。
使いたい人がいたら、適当に使って。
ネットワーク関係と、表示枠関係は動作試験をやっていない。
不審な動作があったので、ついでに記載。
DimChk42で新規にDialogAppAsMainのテンプレートを使って作成。
その後をDimChk42の内容をDimChk42B, DimChk42C, DimChk42Dにコピーして試験を続けた。
DimChk42AはDimChk42の名称を変更したもの。
DimChk42A内 BAKディレクトリーを消そうとしたら消えない。ReadOnlyになっていたので、これを解除して消去した。
そしたら、DimChk42B, DimChk42CのBAKディレクトリーも一緒に消えてしまった。
どこをどうしているのか、わからないけどOS由来の不審な挙動か、FBEが何かやっているのか、わからない。
OS由来の仕様の可能性が高い。
163(2): デフォルトの名無しさん [] 2017/07/13(木) 23:00:12.66 ID:jVjH3qh4(1) AAS
>>140 DBCSがらみの処理は、ほぼ終わりが見えてきた。
主だったルーチンは C:\tool\FreeBASIC\inc\win\shlwapi.bi を参考にしてくれ。
DBCSがらみは C:\tool\FreeBASIC\inc\win\winnls.bi だけではあるが、ファイル名処理に絡んで一部ルーチンが他の*.BIにも存在する。
Fun StrCmpNI()等で、DBCSの比較が可能なシステム参照が存在する。
文字関数は、外部ﾘﾝｸ[html]:makoto-watanabe.main.jp 等が存在する。
VBでは、文字数で規定している。全角文字の「１２３」がVBでは３文字、FBでは６文字になる。
文字数で位置を指定する場合と、文字位置(DBCS1バイト目)を指定する場合の2つを作成する必要がある。
VBに移植したときに、削除したルーチンを復活させる必要もある。これは、表示文字に限って使うルーチンで、
QBmidString(Astring, STpoint, Haba) というMID$()関数を想定したときに、
文字幅 Haba の値によって、DBCSの途中で途切れてしまう場合が発生する。
途切れた文字を含めて返す場合と途切れた文字を削除して返す場合の２通りを考える必要がある。
QBmidString("１２３", 3,3)で、「２３」と返すか「２」と返すかの違い。
同様に、Left$(), Right$()でも発生する問題だ。表示ルーチンなので、じばけを防ぐ程度の問題であり、少しぐらい表示部位が乱れても気にしない(余分に空白を確保しておく)場合となる。
この後に待っているのが、フォント関係。
外部ﾘﾝｸ[html]:makoto-watanabe.main.jp
なんてあるけど
外部ﾘﾝｸ[html]:euc.jp
をカバーしないと日本語化が終了しない。
現時点において、実行中にフォントの切り替えに成功していない。前途多難である。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.313s*