ライブラリ作者への連絡についてNo.38448
fzok4234 さん 20/10/06 00:30
 
現在ライブラリに掲載されているマクロや強調表示などの開発者さんへの
不具合報告などの確実な連絡方法がわかりません。

当方において現在、こみやんま氏のhm.NET v1.701で不具合が出ており、
https://www.maruo.co.jp/turukame/4/x00614_.html?a=4#614
にて報告させていただきました。
しかし10日経った現在、一向に返答がなく、またこみやんま氏のサイト
http://xn--pckzexbx21r8q9b.net/
にも不具合報告のためのメールアドレス等がなく、こちらから連絡の取りようが
ない状態です。このため、hm.NETから呼び出されるDLLの作成に支障をきたして
おります。

現在、ライブラリの「データの登録」フォームにはメールアドレスなどの
確実な連絡手段の掲載が義務付けられていないため、掲載物に不具合が
見つかっても確実に報告ができないのが現状です。




[ ]
RE:38448 ライブラリ作者への連絡についてNo.38449
秀まるお2 さん 20/10/06 09:10
 
 ここのサポート会議室に入会するのにメールアドレスが必要で、そのメールアドレ
スは僕(というか、フォーラム管理者)には分かります。

 そのメールアドレスで一回連絡してみます。

 進捗があったらまたお返事させていただきます。

[ ]
RE:38449 ライブラリ作者への連絡についてNo.38450
fzok4234 さん 20/10/06 09:14
 
御社での対応ありがとうございます。

[ ]
RE:38450 ライブラリ作者への連絡についてNo.38451
秀まるお2 さん 20/10/07 14:22
 
 今のところお返事が無いのですが、作者のこみやんまさんはgithubにアカウントを
持っておられるようです。

   https://github.com/komiyamma

 GitHub経由で連絡する手段があるのかもしれませんが、難しいみたいな話です。

 参照:https://qastack.jp/webapps/29197/any-way-to-contact-a-user-on-github

 GitHubにソースコードも上がってるようなので、ご自身でビルドしてデバッグする
って手もあるかなぁとは思いますけども。ハードル高いかもしれませんが。

[ ]
RE:38451 ライブラリ作者への連絡についてNo.38452
fzok4234 さん 20/10/07 15:34
 
> GitHubにソースコードも上がってるようなので、ご自身でビルドしてデバッグす
>るって手もあるかなぁとは思いますけども。ハードル高いかもしれませんが。

ソースコードを少し拝見しましたが、C#だけで書かれた純粋な.NETアプリではなくて
C/C++によるWin32アプリであったため、これを自力で修正するにはかなり
Win32プログラミングに精通している必要があるため、.NETプログラミングしか
やっていない自分にとっては非常にハードルが高いでしょうね。


[ ]
RE:38452 ライブラリ作者への連絡についてNo.38454
秀まるお2 さん 20/10/08 15:11
 
 C++でマネージドコードを使ってるので僕もまったく経験無いんですが、ビルドし
てトレースして例外発生箇所を特定して、ネット検索していろいろ試行錯誤してうま
く動くように出来たと思います。

 HmNET.cppの98行目付近にある

        MethodInfo^ m = t->GetMethod(method_name);

 とある所を以下のように直せばうまく動くと思います。

        MethodInfo^ m;
        try {
            m = t->GetMethod(method_name);
        }
        catch (Exception^ e) {
            List<Type^>^ tt = gcnew List<Type^>();
            int i;
            for (i = 0; i < args->Count; i++) {
                tt->Add(args[i]->GetType());
            }
            m = t->GetMethod(method_name, tt->ToArray());
        }

 どうでしょうか。

 Visual Studio 2019にソリューションを読み込んで、変換とかが入りましたが、う
まくビルドは出来ました。ソリューションの中「hm.NET」の上でマウス右ボタンメニ
ューを出して「ビルド」とすると、hmNET.dllがビルドできると思います。普通に
「ビルド」メニューからビルドするとdllのビルドにならず、static-libraryのビル
ドになってしまいました。

[ ]
RE:38454 ライブラリ作者への連絡についてNo.38455
fzok4234 さん 20/10/09 06:11
 
わざわざソースコードの修正方法の考案ありがとうございます !!

当面はこの修正を行った「サイトー企画版hm.NET」でしのげることができると
思います。あとは、本家こみやんま氏がこの修正に準じた新バージョンを
リリースするのを待つだけです。


[ ]
RE:38455 ライブラリ作者への連絡についてNo.38471
秀まるお2 さん 20/10/12 17:28
 
 Issuesって所に書き込むことが出来たと思います。

https://github.com/komiyamma/hidemaru-net/issues

 これ見てくれるといいですが。

[ ]
RE:38471 ライブラリ作者への連絡についてNo.38474
fzok4234 さん 20/10/12 19:53
 
GitHubにも意見などの書き込みができるのですね。

一応こちらからも、こみやんま氏のTwitterアカウントのプライベートメッセージに
10月2日付けで不具合報告の書き込みは行っていますが、まだ返事がありません。


[ ]
RE:38471 ライブラリ作者への連絡についてNo.38500
fzok4234 さん 20/10/21 10:54
 
最初の投稿からもうすぐ1ヵ月経とうとしているのに、こみやんま氏の方からの連絡
は一向に
ありませんね。GitHubとTwitterの方も同様です。

このような状況から思ったことがあるのですが、ライブラリへの登録で、著作権をサ
イトー企画に
譲渡する形でビルド/バグフィックス/アップデートなどの管理をサイトー企画に全て
任せる
オプションを設ける、という案はどうでしょうか?

マクロや強調表示などのライブラリをざっと眺めていると、強調表示の対応言語バー
ジョンが
古かったり、DLL形式のマクロでは64bitビルドが行われず32bit版秀丸エディタのみ
対応と
なっていたり、アップロードされている書庫形式がセキュリティ上問題のあるLHA形
式だったりなど、
アップデートなどが全く行われずに管理放棄された状態の物が散見されます。もちろ
ん、
ライブラリの開発者に悪気があるわけではありません。しかし、数百KBにも及ぶ強調
表示や
DLLにビルドされたマクロ等、もはやれっきとした「アプリ」としての性格を持った
ライブラリは
きちんと管理などのサポートがなされている事が望ましいと感じます。

とりわけ、今回のhm.NETに関しては、マクロと.NETのマネージドコードとの連携を行
う上で
無くてはならない存在のため、サイトー企画側でも管理がされていればと思うばかり
であります。
通常、秀丸マクロとの連携に対応している別プログラムは原則としてC/C++言語を用
いてWin32 APIを
バリバリ使用する「ネイティブコード」に限定されています。しかし、ネイティブプ
ログラミングと
いうのは現状、生のポインターを扱うためバッファーオーバーフローなどの回避のた
め最善の限りを
尽くさねばならないこと、ヒープ領域に書き込んだデータは手動で開放しなければな
らないこと、
それらのスキルを身に着けた上で複雑怪奇で危険なWin32 APIを触らねばならないこ
と等、今時の
.NETやJavaやPython等の生ポインターが無くガベージコレクション等の便利な機能の
そろった
オブジェクト指向なマネージドプログラミングしか行っていない人にとっては極めて
敷居が高い
物となっています。そのような中で、もし秀丸マクロと.NETやJavaやPython等の「マ
ネージドコード」との
連携を実現させるDLLが存在するならば、それは正に夢のような「魔法のDLL」であり、
現在主流の
マネージドプログラマーにとって無くてはならない存在となります。

今後秀丸エディタが生き残るうえで、マクロとの連携プログラムが敷居が高くかつ危
険なアンマネージド
コードでしか作ることが出来ないという事は、マネージドコードが主流の昨今の情勢
下では大きな
痛手になっていると私は感じています。理想としては、マクロとマネージドコードと
の連携機能が
「秀丸エディタの生き残りを賭けて」初めから秀丸エディタに実装されいることが望
ましいと
私は思いますがいかがでしょうか?


[ ]
RE:38500 ライブラリ作者への連絡についてNo.38503
秀まるお2 さん 20/10/21 16:12
 
 いろいろ問題があるようですが、うちの会社的にいくらでも対応できる訳でもない
ので、なかなか難しい所ではあります。

 とりあえず、ライブラリにアップロードしていただく時に、著作権や改変について
申告してもらうというのは1つのアイデアとしていいかなぁと思います。

 □ 第三者による改変と、改変されたバージョンの公開を許可する
   (ただし改変元が何であるかの表示は必要とする)

 □ サイトー企画による改変と、改変されたバージョンの公開を許可する
   (ただし改変元が何であるかの表示は必要とする)

 の2つのチェックマークを付けたらいいかなぁと思います。

 マクロなら僕の方で直すのは対応できると思いますが、今回のようなC++言語やそ
の他の言語で書かれた物は、直せない可能性もあるし、そもそもソースコードが公開
または添付されてなければ直しようが無いですけども。

 マネージドコードで作成されたDLLを秀丸マクロから呼び出すことについてのニー
ズはちょっと僕も分からないのですが、しいてサイトー企画で対応するとしたら、こ
みやんまさんがすでに作成された物があるので、それをサイトー企画で改変メンテナ
ンスさせてもらう形が一番いいかなぁと思います。ゼロから作るのはちょっと無理が
ありそうな気がします。

 とりあえず、ライブラリの登録フォームの改良だけ一回トライしてみます。

[ ]
RE:38503 ライブラリ作者への連絡についてNo.38505
fzok4234 さん 20/10/21 17:13
 
ご検討のほうありがとうございます。

> とりあえず、ライブラリにアップロードしていただく時に、著作権や改変について
> 申告してもらうというのは1つのアイデアとしていいかなぁと思います。
>
> □ 第三者による改変と、改変されたバージョンの公開を許可する
>   (ただし改変元が何であるかの表示は必要とする)
>
> □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>   (ただし改変元が何であるかの表示は必要とする)
>
> の2つのチェックマークを付けたらいいかなぁと思います。
>
> マクロなら僕の方で直すのは対応できると思いますが、今回のようなC++言語や
> その他の言語で書かれた物は、直せない可能性もあるし、そもそもソースコードが
> 公開または添付されてなければ直しようが無いですけども。

このオプションを選択するときには、ソースコードおよびビルド方法の説明の
公開/添付を義務付けしたほうが良いでしょう。また、バイナリの掲載については、
サイトー企画側でビルドおよびデジタル署名の埋め込みを行ったものを掲載する
という方針にした方が良いと思います。これは、ウイルス混入を防止するための
「審査」を兼ねてのことです。

> マネージドコードで作成されたDLLを秀丸マクロから呼び出すことについてのニー
>ズは
> ちょっと僕も分からないのですが、しいてサイトー企画で対応するとしたら、
> こみやんまさんがすでに作成された物があるので、それをサイトー企画で改変メ
>ンテナンスさせて
> もらう形が一番いいかなぁと思います。ゼロから作るのはちょっと無理がありそ
>うな気がします。

約1ヵ月も連絡が無いという事は、縁起の悪い話ですがこみやんま氏本人が
他界されたのではと疑ってしまいます。こみやんま氏は.NETのほかにJavaや
Python等とマクロとの橋渡しDLLをオープンソースで公開しています。もしもの
時も考慮して、こみやんま氏本人に無許諾でこれらのDLLの管理をサイトー企画側で
行うのも良いかもしれません。



[ ]
RE:38503 ライブラリ作者への連絡についてNo.38506
Iranoan さん 20/10/21 17:22
 
秀まるおさんこんにちは Iranoan です
>  とりあえず、ライブラリにアップロードしていただく時に、著作権や改変につい
>て申告してもらうというのは1つのアイデアとしていいかなぁと思います。
そういえば、ライセンスについて明示していないケースも有りそうですね

>  □ 第三者による改変と、改変されたバージョンの公開を許可する
>    (ただし改変元が何であるかの表示は必要とする)
>
>  □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>    (ただし改変元が何であるかの表示は必要とする)
>
>  の2つのチェックマークを付けたらいいかなぁと思います。
これに加えて、
□ その他 [                ]
を用意して、既存のライセンスを書き込めるようにしてはどうでしょう?
PDS, GPL, BSD, Apache License などを書き込めるようにしておくわけです

[ ]
RE:38506 ライブラリ作者への連絡についてNo.38507
秀まるお2 さん 20/10/21 17:35
 
 ライブラリの仕組みを今からいろいろいじるのはちょっと大変なので、やっぱり、

>  □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>    (ただし改変元が何であるかの表示は必要とする)

 だけ追加して、その情報はあくまでサイトー企画にだけ分かるようにしようかなぁ
と思います。

 あと、連絡先のメールアドレスを入れていただく欄も無いので、それも追加しない
といけないです。(前々から思ってたことではありますが)

 この辺の改変は、ライブラリの登録フォームをいじる+アルファ程度で出来そうな
気がするので。

> □ その他 [                ]
> を用意して、既存のライセンスを書き込めるようにしてはどうでしょう?
> PDS, GPL, BSD, Apache License などを書き込めるようにしておくわけです

 ライブラリにこの辺の表示をする機能を追加するのはちょっと大変なので、やっぱ
りこの辺はやめとこうと思います。

 ぼちぼち暇を見て対応しようと思います。

[ ]
RE:38505 ライブラリ作者への連絡についてNo.38508
秀まるお2 さん 20/10/21 17:37
 
 こみやんまさんくらいの能力のある方だと何か他の仕事されてるんじゃないかとい
う気もしますけども・・・。日本にいないかもしれないし。

> こみやんま氏は.NETのほかにJavaや
> Python等とマクロとの橋渡しDLLをオープンソースで公開しています。もしもの
> 時も考慮して、こみやんま氏本人に無許諾でこれらのDLLの管理をサイトー企画側で
> 行うのも良いかもしれません。

 GitHubに公開されてる物の改変および改変物の公開とかのルールがどこかにあって、
もしも僕が勝手に改変して公開してもいいってことなら対応してもいいですが・・・。

 あんまり余計なことをして問題になるのもいやなので、とりあえずはやめとこうと
思います。

[ ]
RE:38508 ライブラリ作者への連絡についてNo.38509
でるもんたいいじま さん 20/10/21 18:27
 
でるもんた・いいじまです。

> > もしもの時も考慮して、こみやんま氏本人に無許諾でこれらのDLLの
> > 管理をサイトー企画側で行うのも良いかもしれません。
>
> GitHubに公開されてる物の改変および改変物の公開とかのルールが
> どこかにあって、もしも僕が勝手に改変して公開してもいいって
> ことなら対応してもいいですが・・・。

GitHubとしての統一ルールはないようですが、hm.NETに関しては「MITライセンス」
と明記されています。

なので、誰でも自由に修正・改良できますし、そうやって手を入れたバージョンを再
配布するのも自由です。

#GitHubの当該フォルダに LICENSE.txt というファイルがあって、
#そこに英語でライセンスの内容が書いてあります。
#MITライセンスの日本語訳は、ここの目次ページへリンクしておくのがいいでしょう:
# https://licenses.opensource.jp/

その一方で、修正履歴(リポジトリ上の「History」をクリック)を見ると概ね1年間
隔で大きな修正に取り組んでいるようで、こみやんま氏は単純に多忙という可能性が
高そうです。

☆ ☆ ☆

なので落としどころとしては、このあたりだと思います:

@当分のあいだ、今回の修正を入れたDLLをhide.maruo.co.jpあたりで配布する。
 ※hm.NETの具体的な使い方はそちらには記載せず、必要に応じて
  詳しいサイトへの誘導を行う。
 ※今回の修正内容をdiffファイルか何かにして、DLLと同様に配布する。
  ソースコード全部を再配布する必要はない。

Aこみやんま氏と連絡が取れ次第、公式版に今回の修正内容を反映して
 いただく。

Bその後の扱いについては別途検討。

☆ ☆ ☆

以下、余計なお節介かとは思いますが、今回の修正内容のdiffを添付します。
ファイルの文字コードはShift_JISになっていますね。

--- hmNET.cpp.orig      2020-10-21 18:18:17.014423000 +0900
+++ hmNET.cpp   2020-10-21 18:20:09.654593400 +0900
@@ -95,7 +95,20 @@
                        TraceMethodInfo( assm_path, class_name, method_name);
                        return nullptr;
                }
-               MethodInfo^ m = t->GetMethod(method_name);
+
+               MethodInfo^ m;
+               try {
+                       m = t->GetMethod(method_name);
+               }
+               catch (Exception^ e) {
+                       List<Type^>^ tt = gcnew List<Type^>();
+                       int i;
+                       for (i = 0; i < args->Count; i++) {
+                               tt->Add(args[i]->GetType());
+                       }
+                       m = t->GetMethod(method_name, tt->ToArray());
+               }
+
                Object^ o = nullptr;
                try {
                        // デタッチ関数の時に、引数が無いパターンを許す

[ ]
RE:38500 ライブラリ作者への連絡についてNo.38510
でるもんたいいじま さん 20/10/21 19:51
 
でるもんた・いいじまです。順番が前後しますが…。

> このような状況から思ったことがあるのですが、ライブラリへの登録で、
> 著作権をサイトー企画に譲渡する形でビルド/バグフィックス/アップデート
> などの管理をサイトー企画に全て任せるオプションを設ける、という案は
> どうでしょうか?

秀まるおさんからコメントが付きましたが…

コミュニティによっては、すべての参加者が特定のライセンス条項に従うよう
求めているところがありますね。
Mozilla Firefox/Thunderbird の開発コミュニティなどが典型的ですが、
OS界隈でもLinux陣営は極力GPL適合のコードだけでまとめようとしていて
(GPLなものがなければわざわざ作り直してしまうこともあります。
 OpenSSLの代替としてGnuTLSが開発されたとか)、逆にFreeBSD界隈では
GPLを強制するコードをシステムの中核からは排除しようとしているとか。

> マクロや強調表示などのライブラリをざっと眺めていると、
...
> アップデートなどが全く行われずに管理放棄された状態の物が散見されます。
> もちろん、ライブラリの開発者に悪気があるわけではありません。

これは今のライブラリの仕組みを継続する限り、難しいですね。
今から作り直すとしてもGitあたりの劣化コピーになっちゃうでしょうし、
かといってGitやSubversionといった既存のツールは高機能すぎて敷居が高い。

☆ ☆ ☆

それと、後半のネイティブコード(アンマネージドコード)とマネージド
コードの比較ですが、これは完全に神学論争だと思います。

マネージドバイナリを自作して使いたいという需要があることは何となく
理解できましたが、私の交際範囲にはマネージドコードを日常的に書いて
いる人が誰も思い当たらないので、正直言って実感がわかないのです。

なので、マネージドな開発環境が今は主流だというご主張についても、
「それは、どういう母集団での話ですか?」
というのが私個人の率直な感想です。

☆ ☆ ☆

もう一つ、秀丸はいまだに Windows 98 もサポート対象にしています。
工作機械の制御用などでいまだに需要があるからです。
(たぶん、いまWindows 98で動いているマシンが物理的に壊れたら、
 Windows XPかWindows 7あたりでリプレースされるでしょう。)

このへんも気になりますし、上記のように「どれだけ需要があるのか」
という疑問もありますので、今のところは秀丸本体には組み込まずに、
独立したDLLのままにしておいてほしいです。
(一緒に配布するだけなら特に問題はないと考えますが。)

[ ]
RE:38507 ライブラリ作者への連絡についてNo.38511
h-tom さん 20/10/21 22:53
 
h-tom です。

> ライブラリの仕組みを今からいろいろいじるのはちょっと大変なので、やっぱり、
>
>>  □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>>    (ただし改変元が何であるかの表示は必要とする)
>
> だけ追加して、その情報はあくまでサイトー企画にだけ分かるようにしようかなぁ
>と思います。
改変するかもしれない理由を書いておいた方がいいのでは?
・マクロの場合、秀丸エディタのバージョンアップに伴い、動作しなくなった場合
・強調表示の場合、言語のバージョンパップに伴う変更
など。

しかし、個人的には「サイトー企画」さんがそこまで頑張らなくてもいいのでは、
と思いますけどね。

[ ]
RE:38511 ライブラリ作者への連絡についてNo.38512
石田 さん 20/10/22 00:52
 
私も初歩的なマクロをライブラリに登録させてもらっていますが、マクロ本体の他に、
使用説明書に利用者さんからの問い合わせ用に、作者連絡先のメールアドレスを明記
しています。

>こみやんま氏本人に無許諾でこれらのDLLの管理をサイトー企画側で行うのも良いか
>もしれません。
 利用者さんの問い合わせに返答しない作者さんの問題で、一々「サイトー企画さ
ん」が面倒を見る性格じゃないと思います。これをやり始めたら、「サイトー企画」
の本業が成り立たなくなると思います。

>しかし、個人的には「サイトー企画」さんがそこまで頑張らなくてもいいのでは、
>と思いますけどね。
 同感です。マクロを公開している以上、利用者からの問い合わせに応じるために
メールアドレスを明記するのが作者の道義だと思います。マクロ作者--利用者間の
「無言の関係性」みたいなのがあると思います。

# 開発放棄して、返答したくないなら別ですが…………。

[ ]
RE:38510 ライブラリ作者への連絡についてNo.38513
fzok4234 さん 20/10/22 07:51
 
> マネージドバイナリを自作して使いたいという需要があることは何となく
> 理解できましたが、私の交際範囲にはマネージドコードを日常的に書いて
> いる人が誰も思い当たらないので、正直言って実感がわかないのです。
>
> なので、マネージドな開発環境が今は主流だというご主張についても、
> 「それは、どういう母集団での話ですか?」
> というのが私個人の率直な感想です。

Stack Overflowによる2019年の使用言語ランキング
https://insights.stackoverflow.com/survey/2019#technology-_-programming-scripting-and-markup-languages
では確かに、JavaScript/Python/Java/C#がそれぞれ1位/4位/5位/7位であるのに対し
て、
C++とCがそれぞれ9位と11位となっており、マネージド言語がアンマネージド言語を
追い抜いて
いる結果となっています。一方、国内の日経xTechの2020年の調査
https://xtech.nikkei.com/atcl/nxt/column/18/01068/111100001/
では、1位にC/C++が来ているものの、2位/3位/5位/6位にそれぞれPython/JavaScript
/C#/Javaが
迫ってきており、マネージド言語はもはやマイナーな存在ではないといえます。しか
も、この
日経xTechの記事には「C/C++は組み込み機器や処理速度が求められるシステムに利用
される
ことが多い」とのことで、よほど処理速度にこだわらなければ秀丸マクロの連携プロ
グラム
(もちろんデスクトップアプリであり組み込み機器の制御コードでないのは自明)がC/
C++で
なければならないことはない思います。

> もう一つ、秀丸はいまだに Windows 98 もサポート対象にしています。
> 工作機械の制御用などでいまだに需要があるからです。
> (たぶん、いまWindows 98で動いているマシンが物理的に壊れたら、
>  Windows XPかWindows 7あたりでリプレースされるでしょう。)
>
> このへんも気になりますし、上記のように「どれだけ需要があるのか」
> という疑問もありますので、今のところは秀丸本体には組み込まずに、
> 独立したDLLのままにしておいてほしいです。
> (一緒に配布するだけなら特に問題はないと考えますが。)

もちろん、hidemaru.exe自体にマネージドコード連携機能を追加するのはそれこそ
「大改造」であり、
旧来の環境との互換性の問題が生じる危険性があります。そこで、マネージドコード
連携機能は
別DLLにして同梱配布し、使用時はこれをloaddll()/freedll/dllfuncw()/dllfuncstr
w()する形が
良いと思います。hm.NETはこのようにして使いますし、秀丸エディタのファイルマ
ネージャー枠と
アウトプット枠もそれぞれHmExplorerPane.dllとHmOutputPane.dllという別DLLにな
っていて、マクロから
の使用時はこれをloaddll()/dllfunc()する形をとっています。



[ ]
RE:38512 ライブラリ作者への連絡についてNo.38514
秀まるお2 さん 20/10/22 08:50
 
 とりあえず、チェックマークを用意しておいてサイトー企画の権利を確保しておく
だけはやっておくという話でして、実際にマクロのメンテナンスをうちでやるかどう
かは状況次第でという風にしようと思います。

[ ]
RE:38509 ライブラリ作者への連絡についてNo.38515
秀まるお2 さん 20/10/22 08:55
 
 ライセンス関係に詳しくないので教えていただき助かりました。とりあえず僕が勝
手に改変して公開しても問題なさそうということで・・・

 今の所は様子見させていただきつつ、このままずっとこみやんまさんと連絡が取れ
ない場合は何か対策を考えてみます。

[ ]
RE:38514 ライブラリ作者への連絡についてNo.38518
秀まるお2 さん 20/10/22 14:31
 
 アップロードする用のフォームに、

 □ 作者が音信不通になった場合にサイトー企画での修正および修正版の公開を承
諾します

 ってチェックボックスを付けるようにしました。ここのON/OFF状態は僕の所に届く
だけですけども。

[ ]
RE:38513 ライブラリ作者への連絡についてNo.38519
秀まるお2 さん 20/10/22 14:36
 
 僕もあまり詳しくないのでコメントが難しいのですが、とりあえず、テキストエデ
ィタのマクロ言語でそんなに大それたことはしないだろうし、あんまり本格的でなく
てもいいんじゃないかという思いが根底にあったりしている所ではあります。

 一応、秀丸マクロから呼び出す用の何かをC#で作成するってことだけであれば、CO
Mコンポーネントにしてもらう作戦もあるにはあると思います。

[ ]
RE:38519 ライブラリ作者への連絡についてNo.38521
fzok4234 さん 20/10/22 23:19
 
> テキストエディタのマクロ言語でそんなに大それたことはしないだろうし、あんまり
> 本格的でなくてもいいんじゃないかという思いが根底にあったりしている所ではあ
>ります。

実際、テキストファイルを扱うマクロ操作で、マクロの文や関数だけでは出来ない操
作を
同時に行わなければいけない場面によく出くわします。例えば、フォルダー内のテキ
スト
ファイルのパスを再帰的に列挙したり、編集しようとしているファイルの属性やACL
や監査設定を
変更したり等です。

これらの操作を行うためにはどうしても外部プログラムと連携しなければいけなくな
りますが、
問題はこの外部プログラムの記述の難易度が高くなってはならないことです。現状で
はこれを
アンマネージドコードのDLLにしなければならないため、マクロのみの記述に比べて
極めて
ハードルが高くなってしまいます。C/C++のコンパイルのためにVisual Studioをイン
ストール
しなければいけないですし、先に申した通りアンマネージドなWin32プログラミング
自体が他の
マネージドプログラミングと比較して難易度が大幅に高いです。

それに比べてC#の場合、Windows 10に元からインストールされている.NET Framework
 4.8に
csc.exeというC#コンパイラーが付属しているし、記述の難易度も秀丸マクロよりは
難しいものの
アンマネージドコードに比べるとずっと低いです。あとは、誰かがhm.NETのような橋
渡しDLLを
用意してくれればマクロ+αのやや高度な処理が比較的楽に行えるようになるわけです。


> 一応、秀丸マクロから呼び出す用の何かをC#で作成するってことだけであれば、
> COMコンポーネントにしてもらう作戦もあるにはあると思います。

ここで質問があるのですが、C#のCOMコンポーネント側から
https://help.maruo.co.jp/hidemac/html/200_Dll_Api.html
にある関数およびメッセージを実行することは可能でしょうか?

秀丸マクロからCOMコンポーネントへの一方通行の呼び出しではなく、COMコンポーネ
ントから
秀丸エディタの機能を使う双方向の呼び出しが出来てこそ、外部プログラムを利用す
る価値が
あると思います。



[ ]
RE:38521 ライブラリ作者への連絡についてNo.38522
秀丸担当 さん 20/10/23 15:11
 

COMコンポーネント側から秀丸エディタの関数呼び出しは、loaddllのDLLと同じ位置
づけとなる、同じプロセス内のDLLであれば可能だと思います。

.netをあまり作ったことが無いのですが、Google検索してやり方を調べてみて、.net
のクラスライブラリのDLLをCOMとして登録して呼び出す例を作ってみました。
Hidemaru_GetCurrentWindowHandle関数の32bit値を渡すだけの最もシンプルなもので
す。

●.net側の例
//クラスライブラリでプロジェクト設定 「アセンブリをCOM参照可能にする」「COM
相互運用の機能の登録」が必要。
//管理者で「regasm ClassLibrary1.dll /tlb:ClassLibrary1.tlb」が必要。32bitと
64bitで違うので注意。
using System;
using System.Net;
using System.Runtime.InteropServices;

namespace ClassLibrary1
{
    [Guid("0F3B0368-61E4-4E2D-BB3C-86ADC8DFD602")] //guidgenで生成する適当な
別の値にしてください
    public class Test1
    {
        [DllImport("kernel32.dll")]
        public static extern IntPtr GetModuleHandle(string lpFileName);
        [DllImport("kernel32.dll")]
        public static extern IntPtr GetProcAddress(IntPtr hModule, string lp
ProcName);
       
        public delegate IntPtr HIDEMARU_GETCURRENTWINDOWHANDLE();
       
        public int TestMethod()
        {
            IntPtr hmod = GetModuleHandle(null); //hidemaru.exe自身
            IntPtr pfn = GetProcAddress(hmod, "Hidemaru_GetCurrentWindowHand
le");
            HIDEMARU_GETCURRENTWINDOWHANDLE Hidemaru_GetCurrentWindowHandle
= (HIDEMARU_GETCURRENTWINDOWHANDLE)Marshal.GetDelegateForFunctionPointer(pfn,
 typeof(HIDEMARU_GETCURRENTWINDOWHANDLE));
            int hidemaruhandle = 0;
            if( Hidemaru_GetCurrentWindowHandle != null ) {
             hidemaruhandle = (int)Hidemaru_GetCurrentWindowHandle();
            }

            return hidemaruhandle; //マクロのCOM呼びだしはIntPtrでなくてint
で、ウィンドウハンドルは32bit値に収まる
        }
    }
}

●マクロ側の例
#obj=createobject("ClassLibrary1.Test1");
if(getresultex(10)!=0) {
    message "マクロのhidemaruhandle:\n"
        + str(hidemaruhandle(0))+"\n\n"
        +".netのDLLで呼んだHidemaru_GetCurrentWindowHandle:\n"
        + str(member(#obj,"TestMethod"));
} else {
    message "createobject失敗";
}
endmacro;




Hidemaru_*の関数は、ポインタで受け取るものやHGLOBALを扱うものがあるので、こ
れらを扱う場合はkernel32のGlobalAllocやGlobalLock等を使う必要があるので、も
うちょっと手間になると思います。
一通り試してみてヘルプの説明ページを作ったほうがいいかもしれません。

[ ]
RE:38522 ライブラリ作者への連絡についてNo.38523
fzok4234 さん 20/10/23 16:57
 
わざわざ.NETのクラスライブラリのCOMコンポーネント化のサンプルの御提示ありがとう
ございます !!

COMコンポーネントでもP/Invokeによる秀丸エディタの関数とメッセージが利用可能
なのですね。

ただ、問題なのはRegAsm.exeでのCOMコンポーネントの登録を管理者が行わないとい
けない
ことです。つまり、制限ユーザーが秀丸マクロの.macファイルと同じ感覚でマクロの
デフォルト
フォルダーの
%AppData%\Hidemaruo\Hidemaru\Macro
にCOMコンポーネントの.dllファイルを保存して、.macファイルから自由にロードす
るといったことが
出来ないということです。マクロ関数のcreateobject()はレジストリに登録済みのPr
ogIDを
指定することになっており、COMコンポーネントのファイルパスは受け付けません。R
egAsm.exeや
Windows標準アプリのregsvr32.exeでの登録無しで直にCOMコンポーネントのファイル
をパス文字列で
ロードするマクロ関数/文があれば良いと思うのですが... 。



[ ]
RE:38523 ライブラリ作者への連絡についてNo.38524
秀丸担当 さん 20/10/23 17:38
 

登録なしでCOMオブジェクトを作成するのは、自分でもどうにかならないかと思って
います。
たぶんですが、例えば
#obj = crateobject("c:\\x\\y.dll","{XXXX-XXX...}");
といったように、ファイル名とCLSIDを同時に書いて、CLSIDがわかればそれを使う方
式にすればできる可能性はあると思います。
.netで作成されたものに通用するかどうかわからないですが、試してみようと思いま
す。

[ ]
RE:38523 ライブラリ作者への連絡についてNo.38525
秀丸担当 さん 20/10/26 15:07
 

COMを登録せずにやるのを試してみたのですが、.netでなく外部EXEでもないDLLであ
ればファイル名とGUIDで一応可能でした。(メソッド等も登録に依存していなければ)
.netの場合はだいぶん仕組みが違うみたいで、同じ方式は使えずちょっと厄介なよう
でした。
可能か不可能かでいえば可能だと思いますが、とりあえずは普通のDLLを対応してか
らまた検討したいと思います。

[ ]
RE:38523 ライブラリ作者への連絡についてNo.38526
秀丸担当 さん 20/11/04 09:59
 

V8.96β1を公開して、.netのほうもできるように対応しています。
.netの場合はCLSIDではなく以下のような感じで記述できます。
#obj = crateobject("c:\\x\\y.dll","ClassX.TestX");

以下のページの「先行開発バージョンはこちら」からダウンロードできます。
https://hide.maruo.co.jp/software/hidemaru.html

[ ]
RE:38526 ライブラリ作者への連絡についてNo.38527
fzok4234 さん 20/11/04 12:12
 
早速の対応ありがとうございます !!

[ ]
RE:38527 ライブラリ作者への連絡についてNo.38607
こみやんま さん 20/12/17 18:04
 
こみやんまです。
(相変わらずハンドル名が違うかもしれません、変更しても変更されない...orz)

こちら メソッドのオーバーロード呼び出しを v1.711 としてアップしました。(自
サイトのみ)

https://xn--pckzexbx21r8q9b.net/?page=nobu_tool_hm_dotnet

秀まるおさん、fzok4234さんをはじめ、皆さんに色々とお手数をかけていただき申し
訳ないです。(ありがとうございます)



[ ]
RE:38607 ライブラリ作者への連絡についてNo.38608
fzok4234 さん 20/12/17 22:31
 
更新ありがとうございます !!


[ ]