[質問]ファイルタイプ別の設定の操作No.09408
fzok4234 さん 21/05/28 03:24
 
お疲れ様です。

さて、ファイルタイプ別の設定をマクロから管理する際に、以下のやり方がわかりま
せん。

 1. 登録されている「設定のリスト」の名前を全て列挙すること。
    currentconfigsetキーワードでは現在の「設定のリスト」の名前のみを1個だけしか
    取得できません。
 2. 特定の「設定のリスト」を削除すること。
 3. 1つの「設定のリスト」に対応する「ファイルタイプ」の名前(拡張子)を全て列
挙すること。
 4. 特定の「ファイルタイプ」を対応する「設定のリスト」から削除すること。
 5. 特定の「設定のリスト」における「複数行コメント」の項目を操作すること。
    .hilightファイル上の「複数行コメント」の書式が理解できれば何とかなるので
すが...。

いずれもマクロヘルプに具体的な方法が記載されておりません。Googleで検索しても
有用な情報を
得られませんでした。

できれば以下の条件を満たす形でマクロを記述できるようになりたいと思っています。
 A. レジストリを直接操作しない。
    レジストリの仕様に関しては、
    https://www.maruo.co.jp/hidesoft/2/x38894_.html#38898
    などで示されている通り「非公開」かつ「固定化されていない」ため、これに依
存すると
    下位互換性を保つことができません。
 B. 新しい文/関数/キーワードの実装などマクロ仕様の改善を要求しない。
    御社に多大な開発コストを発生させる「無茶な要望」を出すことは正直心苦しい
です。
    現行のマクロ仕様のままで問題を解決したいと思っています。


[ ]
RE:09408 [質問]ファイルタイプ別の設定のNo.09411
秀丸担当 さん 21/05/28 16:27
 

ファイルタイプ別の設定のリストは、マクロ上からの制御はできないです。
現状でやるとしたら、レジストリを見たりするしかないですが、レジストリだとして
もキーを列挙する文なども無いので、DLLやCOMオブジェクト等でやるしかないと思い
ます。
何らかの文などを追加するしかなく、現状ではできないです。

[ ]
RE:09411 [質問]ファイルタイプ別の設定のNo.09413
でるもんたいいじま さん 21/05/28 16:47
 
でるもんた・いいじまです。

> ファイルタイプ別の設定のリストは、マクロ上からの制御はできないです。
> 現状でやるとしたら、レジストリを見たりするしかないですが、
> レジストリだとしてもキーを列挙する文なども無いので、

あー、そこ(レジストリキーの列挙ができない)に落とし穴がありましたか。

私自身も、複数のファイルタイプの設定を見比べながら細かい部分を同期させる機能
があったらいいなあ、いっそ自分で作ろうか、と考えていたところなので、少し残念
です。

ということでfzok4234さんに提案なのですが、以前にも提案した通り、秀丸のレジス
トリの内容(特にREG_BINARYの中身)をJSONか何かの形式に書き出すツール、逆にそ
の形式のデータ(設定の一部分だけのものを含む)をレジストリに注入するツール、
を書いていただければ助かるのですが、いかがでしょう?

とりあえず現状の仕様に合わせて32bitと64bitのコンソールアプリ(標準C++の機能
以外にはWin32/64 APIしか使わず、極端にいえばMinGWでもコンパイルが通るもの)
を作っていただいて、その後の仕様変更に伴うメンテナンスはサイトー企画さんにお
任せ、でいかがでしょうか。

レジストリに書いてある設定を操作したいけど仕様が分からない、という需要は過去
にもそれなりにあったように思いますし、私自身としてもマクロでそういうツールを
利用できると助かるのですが。

[ ]
RE:09413 [質問]ファイルタイプ別の設定のNo.09414
fzok4234 さん 21/05/28 17:36
 
> (特にREG_BINARYの中身)

設定管理ツールの自作で一番ネックになる部分です。現行バージョンのバイナリデー
タの書式を
サイトー企画さん側から教えてもらわないといけませんね。それは結局「レジストリ
ヘルプ」を提供して
ほしいことを要望することとなってしまいます。

それができなければひたすら「GUIからの設定変更」=>「設定変更の前後でのバイナ
リデータの変化」を
解析するというリバースエンジニアリングをしなければならず、相当な時間と労力が
かかりそうです。

> (標準C++の機能以外にはWin32/64 APIしか使わず、極端にいえばMinGWでもコンパ
>イルが通るもの)

基本的に当方では今までほとんどC#で「マネージドコード」を開発してきたため、C/
C++でWindows APIを直に叩いて
生ポインタを弄りメモリ開放も手動で行うという「アンマネージドプログラミング」
で実用レベルの
アプリを公開できるほどのスキルを持ち合わせておりません。故に、設定管理ツール
を初め秀丸エディタ用の
便利ユーティリティは結局C#でクラスライブラリ(こみやんまさんのhm.Net.dllで使
用)かCOMサーバを
作る公算が大きいです。アンマネージドコードを提供できないことは何卒ご容赦お願
い申し上げます。

もちろんソースコードとバイナリに加えて当方が把握したレジストリ書式の説明書き
をGitHubなどのWeb上において、
サイトー企画さんに間違いがないか添削してもらうこととなります。

もしサイトー企画さんがC#と.NET Frameworkも理解できるのであれば、ソースコード
のメンテナンスをお願い
してもよいだろうと思います。


[ ]
RE:09413 [質問]ファイルタイプ別の設定のNo.09415
でるもんたいいじま さん 21/05/28 17:39
 
でるもんた・いいじまです。自己レスです。

> > レジストリだとしてもキーを列挙する文なども無いので、
> あー、そこ(レジストリキーの列挙ができない)に落とし穴がありましたか。

reg.exeをマクロから呼び出す、という方法が使えそうです。
#reg.exe っていつのバージョンから存在していたんだったか…

でもまあ、レジストリキーの列挙は今後も需要がありそうなので、マクロへの機能追
加を私から要望させてください。getregsubkey() で一つずつ順番に返すのが順当で
しょうか。丸ごと取得する仕様にしてしまった場合、たとえばHKCR直下を指定した時
には秀丸が凍りそうですので…。

☆ ☆ ☆

マクロヘルプの

> openregは、指定されたサブキーが存在しない場合にエラーとなります。
> createregは、指定されたサブキーが存在しない場合は新たに作成してから
> オープンします。
> オープンに成功すると結果コードは1になり、失敗すると0になります。

というくだりですが、「エラーとなります」だとマクロ強制終了なのかresultに0が
返るだけなのか判然としないので、ここは「オープンに失敗します」あたりの表現が
順当ではないでしょうか。ご検討ください。>担当さま

☆ ☆ ☆

一応、現状の「ファイルタイプ別の設定」の保存場所についての仕様を簡単に書いて
おきます。

HKCU\Software\Hidemaruo\Hidemaru\ がツリーの大元。
その直下のRegVerというDWORD値が現在使用中の秀丸のバージョン。
(内部データは16進だったんですね^^ とするとWin98対応のレガシーバージョンの番
号も極論、8.255.255 まで余裕があるわけだ)

キーの名前がピリオドで始まっているものが、ファイルタイプ別設定の対象になって
いる拡張子。そのデフォルト値が設定の名称。
(拡張子以外では例外的に、binaryというキーがバイナリモードを参照している。)

Configサブキーの中に各設定の名前でさらにサブキーがあって、その中には割とわか
りやすい形式で各種設定が入っています。*.txt に適用されるデフォルトの設定は H
idemaru\ 直下の Default\ に(たぶん)同じ形式です。

(一部、DWORDの配列がバイナリで入っている場所もありますが、実際に設定を操作
しながら別画面で逐一モニタしていけば、どこの値が何を示しているのかの特定は容
易でしょう。)

[ ]
RE:09414 [質問]ファイルタイプ別の設定のNo.09416
でるもんたいいじま さん 21/05/28 18:33
 
でるもんた・いいじまです。行き違いになりました。

> > (特にREG_BINARYの中身)
> 設定管理ツールの自作で一番ネックになる部分です。
...
> リバースエンジニアリングをしなければならず、
> 相当な時間と労力がかかりそうです。

「ファイルタイプ別の設定」に限ってはそうでもなさそうです。

HKCU\Software\Hidemaruo\Hidemaru\Default\ がファイルタイプ別設定のデフォルト
のようで(他の各設定は Hidemaru\Config\各設定名\ の中に同様の形式のはず)、
手元の環境では、この中でREG_BINARYなのは下記の4つだけです。

・AutocompConfig → 私は補完機能を使っていないので、調査放棄。
・Colorset → 32bitデータの配列なので、一つ一つ特定していく必要があります。
・ExConfig、Exconfig2 → ここにはAspellプラグイン等の設定が入っているようで
すが("en_US" というバイト列が確認できます)、当面ここは触らない予定。
・FontMap2 → 手元では「長さ0のバイナリ値」になっています。

それ以外はすべて単なる文字列か数値ですから、「パラメータを変えて、レジストリ
エディタで10進・16進の値の変化を確認して」という作業を、ご自分が操作したい範
囲に絞って地道に作業していくだけです。
 
> > 標準C++の機能以外にはWin32/64 APIしか使わず、
> > 極端にいえばMinGWでもコンパイルが通るもの
> 基本的に当方では今までほとんどC#で「マネージドコード」を開発してきたため、
> C/C++でWindows APIを直に叩いて生ポインタを弄りメモリ開放も手動で行うという
> 「アンマネージドプログラミング」で実用レベルのアプリを公開できるほどの
> スキルを持ち合わせておりません。

ありゃ。最近はWindowsの職業プログラマだとそういう人が多いんですかね。

UNIX界隈はいまだに生のC言語が標準ですし(C++の新しめの標準ライブラリを期待で
きるかどうかも怪しい)、スマホ界隈はたぶんJDKと各種開発キットの組み合わせで
しょうし。

> アンマネージドコードを提供できないことは何卒ご容赦お願い申し上げます。

この点は了解しました。何がベストなのか、改めて考えてみます。

#でもfzok4234さんとしても、大学の情報学部1-2年必修レベルくらいの
#アンマネージドコードでコンソールアプリを書く作業は、お時間のある
#ときに一度かじっておいて損はないと思いますよ。

#ちなみに、「あとはSIMD界隈も(これは私も勉強したい)…」と思って
#アマゾンで検索したのですが、日本語の入門書が皆無。残念です。

> もちろんソースコードとバイナリに加えて当方が把握した
> レジストリ書式の説明書きをGitHubなどのWeb上において、
> サイトー企画さんに間違いがないか添削してもらうこととなります。

そうですね。

> もしサイトー企画さんがC#と.NET Frameworkも理解できるのであれば、
> ソースコードのメンテナンスをお願いしてもよいだろうと思います。

そうですね…まあ、満足に書くことはできないかもしれないですけど、完成品の既存
コードを読み解くだけなら特に支障ないと思いますので、もしC#のままでのメンテナ
ンスが困難でも、そのコードを参考にしながら他の言語で作業していただければ問題
ないはずです。

以下余談

ちなみに私自身は C# が全く書けないのはもちろんのこと、WinMain() から始まる W
in32/64 GUI ネイティブアプリ、class CMain から始まるMFCアプリも書けません。
コンソールアプリからピンポイントでWin32 APIを叩くことはできます。

ただ、今のマシンに乗り換えてからというものの、VCもMinGWもまだインストールし
ていません。C/C++でないとできない仕事がほぼゼロに等しくて(ごくまれにC/C++が
必要な場合は、Webホスティング用に借りているFreeBSDマシンで使う)、今はperlや
VBAばっかり書いています。

ただ、個人的にかかわっている別案件で「FreePascal+Lazarus IDE」という環境を
最近導入しまして、これがWin32/Win64ネイティブアプリを吐けるので(いろいろ考
えて、今のところはWin98対応の最終バージョンを選択しました)、何か必要な個所
が出てきたら練習がてら、それでアプリを書いてみようかと思っています。

私としては、まずは DWORD ColorSet[] の解読からですね…

[ ]
RE:09414 [質問]ファイルタイプ別の設定のNo.09418
fzok4234 さん 21/05/31 09:32
 
ただ、よく考えてみると秀丸エディタ本体とは別のツールを用意するということは、
レジストリを操作する
同一ロジックが「本家秀丸エディタ」と「当方提供のツール」という2箇所に重複し
て存在することとなり、
レジストリの仕様の変更/拡張の際には複数個所を同時に修正しないといけない「DRY
原則に従わない」状態と
なって、かえって管理コストの増大や不具合の温床になりそうです。

となると、秀丸エディタ本体が元々持っている環境設定ロジックを操作するマクロ構
文を新設することが
やはり理想なのでは、と思ってしまいます。

しかし、いざマクロ構文の実装となると、それはそれで大掛かりな改修となりそうで
す。というのは、今回
当方で挙げた
 A. 登録されている「設定のリスト」の名前の列挙。
 B. 特定の「設定のリスト」に対応する「ファイルタイプ」の名前の列挙。
および、でるもんたいいじまさんが挙げた
 C. レジストリキー内のサブキー名の列挙。
と、さらに上記に歩調を合わせる形で
 D. レジストリキー内の値の「名前」と「型」の列挙。
はいずれも同じ型の複数の値からなるオブジェクト、すなわち「コレクション」の列
挙であり、しかもこれらの
コレクションの要素数はユーザーの環境次第で際限なく大きくなる性質があるからで
す。これを単純に
windowstate[#index]キーワードやenumcolormarkerlayer(#index)関数などと同様に
インデックス番号で
参照するような実装にすると、一度全ての要素をメモリに読み込む必要があるため、
例えばレジストリキー
HKEY_CLASSES_ROOT\CLSID
内のサブキー名を取得するような場合は「秀丸エディタが固まる」といった問題が生
じてしまいます。

そこで、このようなコレクションは要素を1つ列挙するたびにレジストリなどの実体
から読み込むという仕様に
しないといけないのですが、そのためにはこれらのコレクションには
 0. 次を取得。
 1. スキップ。
 2. 最初に戻る。
 3. 解放。
というようなCOMコレクションと同様な操作が実装されていなければなりません。そ
の結果、これらのコレクションは
やはりCOMオブジェクトと同様に「メモリ上に実体(インスタンス)があって対応する
ハンドル数値で操作する」という
実装にならざるを得ません。

しかし、上記A〜Dの4つのコレクションに対して別々に、しかも既にあるCOM呼び出し
機能とは別に
#objReturn = getxxxxcollection( #obj, #operation, #count );
を設けるのは似たような実装を繰り返し別々に行う「DRY原則に従わない」状態とな
るのでよろしくありません。
となると、これらのコレクションも既存のgetcollection()関数で対応することが望
ましいといえます。

だが、これらのコレクションは「COMオブジェクトではない」秀丸マクロ独自の「一
般オブジェクト」です。上記の実装の
ためには何より先にこの「一般オブジェクト」の機能を実装しなければならなくなり
ます。というのは、今のところ
需要があるのは上記A〜Dの4つのコレクションだけですが、今後他のユーザーの要望
次第ではこのような
「オブジェクト指向」的なアプローチが要求されることが十分考えられます。つまり、
今回の問題を機に今まで秀丸マクロに
無かった「オブジェクト指向」の概念に取り組む必要が生じることになります。

具体的には、この「一般オブジェクト」はcallmethod_returnnum()やgetpropnum()、
先ほど挙げたgetcollection()などの
COMオブジェクト用の構文をそのまま使用して操作するのがマクロユーザーから見て
親しみやすいものと思われます。
「一般オブジェクト」の生成は、例えば上記Aの場合で
#obj = getconfigsets();
とするなど個別の対応だが、使用後の破棄は
COMと共通の
releaseobject #obj;
とするとかです。

いずれにせよ、今回の問題をサイトー企画さん側でマクロ構文の増設で対処すること
も大きな開発コストを生じさせること
になります。

----------------------------------------------------------------------------
----------------------------------

結論を申し上げれば、
・ユーザーが独自の設定管理ツールを用意するのも「地獄」
・サイトー企画さんがマクロ構文の新設で対応するのも「地獄」
・もちろんユーザーに我慢を強いるのも「地獄」
の状況で、問題解決の道のりは非常に遠いものとみられます。



[ ]
RE:09418 [質問]ファイルタイプ別の設定のNo.09419
秀丸担当 さん 21/05/31 12:18
 

レジストリの形式を解析されるのはおすすめはできないのですが、キーの列挙はマク
ロに不足しているので、追加します。
enumregkeyを追加してみています。
foreachのような方式ではなく、インデックスで参照するような方式です。
レジストリにアクセスする文/関数は、ほぼWindows APIのReg*の関数に呼び替えてい
るものになっていて、列挙はRegEnumKeyExに呼び替え、これもインデックスのため、
そのまま渡しているだけみたいな感じです。
列挙中に書き換えがあったらずれが発生する可能性がありますが、そのあたりは仕方
ないことになりそうです。

[ ]
RE:09418 [質問]ファイルタイプ別の設定のNo.09421
でるもんたいいじま さん 21/05/31 14:32
 
でるもんた・いいじまです。

> となると、秀丸エディタ本体が元々持っている環境設定ロジックを
> 操作するマクロ構文を新設することが
> やはり理想なのでは、と思ってしまいます。

これは同意です。

> しかし、いざマクロ構文の実装となると、それはそれで大掛かりな改修と
> なりそうです。というのは、今回当方で挙げた
>  A. 登録されている「設定のリスト」の名前の列挙。
>  B. 特定の「設定のリスト」に対応する「ファイルタイプ」の名前の列挙。
> および、でるもんたいいじまさんが挙げた
>  C. レジストリキー内のサブキー名の列挙。
> と、さらに上記に歩調を合わせる形で
>  D. レジストリキー内の値の「名前」と「型」の列挙。
> はいずれも同じ型の複数の値からなるオブジェクト、
> すなわち「コレクション」の列挙であり、

んー、コレクションの概念を持ち出して一般化するまでのことでもないのでは。

もしかしたらfzok4234さんは、何も知らない状況からいきなりC#・Python・PHPあた
りでプログラマとしてのキャリアをスタートされたのでしょうか。

でも秀丸のマクロはもっと原始的ですから(なにせPerl4.036が「配列のサイズや文
字列の長さを気にしなくていい画期的な言語」という位置づけだった時代の設計をず
っと引きずっています)、シンプルにこんな感じにできそうです。

- - - - キリトリセン - - - -
openreg "CURRENTUSER", @"Software\Hidemaruo\Hidemaru";
call Exit_if_OpenReg_Failed, "秀丸のレジストリトップ";

// var $Ext[];
#nExt = 0;
while (1)
{
 $key = getregsubkey();
 if ( !result ) break;

 if ( leftstr($key,1) != "." )
  continue;

 $Ext[#nExt] = $key;
 #nExt = #nExt+1;
}
closereg;

#nAssoc = 0;
// var $Assoc[];
while ( #nAssoc < #nExt )
{
 openreg "CURRENTUSER", @"Software\Hidemaruo\Hidemaru\" + $Ext[#i];
 call Exit_if_OpenReg_Failed, sprintf("拡張子 '%s' のエントリ", $Ext[#i]);

 $Assoc[#nAssoc] = getregstr("");
 closereg;

 #nAssoc = #nAssoc+1;
}

openreg "CURRENTUSER", @"Software\Hidemaruo\Hidemaru\Config";
call Exit_if_OpenReg_Failed "タイプ別設定のフォルダ";

#nTypes = 0;
// var $Types[];
while (1)
{
 $key = getregsubkey();
 if ( !result ) break;

 $Types[#nTypes] = $key;
 #nTypes = #nTypes+1;
}
closereg;

message str(#nExt) + " 個の拡張子がレジストリに登録されています。\n\n" +
 "「共通」タイプの他に、" + str(#nTypes) + "個の設定が存在します。\n" +
 "ただし、そのすべてが何かしらの拡張子から参照されているとは限りません。";
endmacro;

// エラー処理はここにまとめる
Exit_if_OpenReg_Failed:
 if ( result==true )
  return;

 message sprintf(
  "レジストリのオープンに失敗しました。\n" +
  失敗箇所:%s", $$1);
endmacro;
- - - - キリトリセン - - - -

これは単純に、readregsubkey() という関数をマクロに追加していただくだけで実現
可能です。
あるいは、この構文は容易に getregsubkey(n1) の形に拡張できます。n1を省略した
場合には「前回アクセスした番号の次の数字」の意味になる、としておけばいいでし
ょう。

☆ ☆ ☆

ちなみに、実際のWin32ネイティブAPIでも、サブキーの列挙は「まとめて一つのベク
トルとして受け取る」ではなく「一つずつ順番に受け取る」になっています。

こちら
https://s-kita.hatenablog.com/entry/20120401/1333290793
によると、Win32APIの RegEnumKeyEx() の宣言文はこのようになっています。

LONG RegEnumKeyEx(
  HKEY hKey,                  // 列挙するべきキーのハンドル
  DWORD dwIndex,              // サブキーのインデックス番号
  LPTSTR lpName,              // サブキー名が格納されるバッファ
  LPDWORD lpcName,            // サブキー名バッファのサイズ
  LPDWORD lpReserved,         // 予約済み
  LPTSTR lpClass,             // クラス名が格納されるバッファ
  LPDWORD lpcClass,           // クラス文字列バッファのサイズ
  PFILETIME lpftLastWriteTime // 最終書き込み時刻
)

上記
サイトのサンプルでは、dwIndex に 0, 1, 2, ... と順に増やしながら何度もこの呼
んで、ERROR_NO_MORE_ITEMS==259が返ってくるまでループしています。

サンプルコードを読んた限り、単純にキーを列挙したいだけなら lpReserved、lpCla
ss、lpcClass には何も考えずに NULL を渡しておけばいいようです。Microsoftのド
キュメントによると、lpftLastWriteTime もやはりNULLて問題ないそうです。

[ ]
RE:09419 [質問]ファイルタイプ別の設定のNo.09422
fzok4234 さん 21/05/31 14:34
 
v8.98β10 Float x64にて、以下のマクロ

debuginfo 2 ;
openreg @"CLASSESROOT" , input( @"Subkey Name" , @"" ) ;
  #index = 0 ;
  $name = @"" ;
  while ( 1 ) {
    $name = enumregkey( #index ) ;
    if ( @"" == $name ) {
      break ;
    }
    debuginfo str( #index ) + @" : " + $name + "\U0000000A" ;
    #index = #index + 1 ;
  }
closereg ;
endmacro ;

にてenumregkey()の動作確認ができました。

ただ、マクロヘルプのenumregkey()のページの見出しが
getregstr( s1 )関数, getregnum( s1 )関数
という誤植になっていました。


[ ]
RE:09422 [質問]ファイルタイプ別の設定のNo.09423
でるもんたいいじま さん 21/05/31 14:58
 
でるもんた・いいじまです。
行き違いになりました。

> v8.98β10 Float x64にて、以下のマクロ
>
> debuginfo 2 ;
> openreg @"CLASSESROOT" , input( @"Subkey Name" , @"" ) ;
>   #index = 0 ;
>   $name = @"" ;
>   while ( 1 ) {
>     $name = enumregkey( #index ) ;
>     if ( @"" == $name ) {
>       break ;
>     }

なるほど、enumerationが終わったら空文字列を返す、という実装になったわけですね。

いまWindowsAPIのマニュアルをMSのサイトで読んでいますが、これが新設されたのな
ら enumregvalue() もペアで存在していればバランスがいいかもとか、他にもレジス
トリでいろいろ遊んでみたいなとか、いろいろ考えてしまいます。

まあ、需要がないのに新しい関数・命令を作っても無意味ですから、レジストリ関係
のアイデアは手元で温めておくことにします。

P.S.
ColorSet[] の解読、ほぼ終わっています。
最終的な一覧表はExcel形式の表にまとめてあるので、ドキュメントと合わせてこれ
から自前のサーバの仮ページにアップします。

[ ]
RE:09423 [質問]ファイルタイプ別の設定のNo.09424
でるもんたいいじま さん 21/05/31 15:42
 
でるもんた・いいじまです。

> P.S.
> ColorSet[] の解読、ほぼ終わっています。
> 最終的な一覧表はExcel形式の表にまとめてあるので、
> ドキュメントと合わせてこれから自前のサーバの
> 仮ページにアップします。

ここに置きました。
http://e231.tokyo/@/hm_reg/

Colorset 以外の情報の解析については別途、時間のあるときに。

[ ]
RE:09423 [質問]ファイルタイプ別の設定のNo.09425
秀丸担当 さん 21/05/31 16:12
 
fzok4234さん
いろいろご確認ありがとございます。
>ただ、マクロヘルプのenumregkey()のページの見出しが
>getregstr( s1 )関数, getregnum( s1 )関数

ヘルプの間違いはその通りでした。
また修正しておきます。

でるもんたいいじまさん
>いまWindowsAPIのマニュアルをMSのサイトで読んでいますが、これが新設されたのな
>ら enumregvalue() もペアで存在していればバランスがいいかもとか、

一通り揃えるならenumregvalueもあったらいいと思います。とりあえず現状では必要
性があるかどうかわからないので、そういうネタもあるということに留めておこうと
思います。

[ ]
RE:09424 [質問]ファイルタイプ別の設定のNo.09426
fzok4234 さん 21/05/31 18:43
 
詳細な調査ご苦労さまでした。参考にさせていただきます。




[ ]
RE:09425 [質問]ファイルタイプ別の設定のNo.09428
fzok4234 さん 21/06/01 12:59
 
とりあえず、問題となっている
・登録されている「設定のリスト」の名前の列挙。
・特定の「設定のリスト」に対応する「ファイルタイプ」の名前の列挙。
については「しばらくの間」はenumregkey()で対処することになります。しかし、レ
ジストリの仕様が
「非公開で不定」である以上、やはりマクロ構文という「公開された固定仕様」なア
クセス手段はあった方が
よいと思われます。例えば、以下のような感じです。
$configset = enumconfigset( #index ) ; // バックスラッシュ@"\"で列挙終了。
deleteconfigset $configset ;
$filetype = enumfiletype( $configset, #index ) ; // バックスラッシュ@"\"で列
挙終了。
deletefiletype $configset, $filetype ;

それから、.hilightファイルにおける複数行コメントの記述方法はヘルプに載せてお
いた方がよいでしょう。

時間的に余裕があるときに検討されてみてはいかがと思います。


[ ]
RE:09428 [質問]ファイルタイプ別の設定のNo.09432
秀丸担当 さん 21/06/01 17:26
 

ファイルタイプ別の設定をレジストリに依存しないようにするとしたら、そういった
感じのものがあったらいいと思います。
余裕があったら検討するということでネタということにしておきます。

[ ]
RE:09432 [質問]ファイルタイプ別の設定のNo.09441
fzok4234 さん 21/06/02 08:06
 
一応、登録されている「設定のリスト」の名前は
HKEY_CURRENT_USER\Software\Hidemaruo\Hidemaru\Config
内のサブキー名で、「ファイルタイプ」の名前は
HKEY_CURRENT_USER\Software\Hidemaruo\Hidemaru
内の「.」で始まるサブキー名で(既定)の値がREG_SZで「設定のリスト」の名前とな
っているもので
あることが確認できています。

もしこの「仕様」の変更が決定した場合は、なるべく早く(遅くとも1ヵ月前)に新し
い仕様を発表するか
先ほど例として挙げた4つのマクロ構文を実装するかの対処を行って、
・いきなり予告なく仕様変更されてマクロが動かなくなった!!
という騒ぎが起こらないよう、くれぐれもご配慮くださいますようよろしくお願い申
し上げます。


[ ]