結局PyPi ahkがあってもAutoHotkeyとPythonは混ざらない。
今日も結局ahkとPythonでどうツールとして併用していくかの可能性の検証で終わった。だが一応の結論は出た。昨晩考えた夢物語はすべて消え去った。冷たい現実の成果がここに残った。
（約 3,300文字の記事です。）
PyPi ahkは不完全。GUI関連が全滅
ピュアなAutoHotkeyで動いていたときはサクッとWindowのボタン制御やコンボボックスの指定がドキュメント通りに動いていた。だが今回、ChatGPT先生にahkソースをPyPi ahkでラッピングさせて試してみたら、IDE上でエラーはないのに実行したらエラーが出る。ランタイムエラーだ。なんで？
と思ってエラー箇所を調べてみたら、2つの原因で2時間持って行かれた😭
公式ドキュメントが間違っていた💢（Implementedと書かれていたが実際にはNot Implementedだった）
PyCharm側のahkアドオンが不完全？存在しない関数で書いても波線エラー表示がされない
ahkを扱っている以上、実はv1にはあってv2にはない関数も存在する。私はv2メインで扱っているのでそれが原因か？と最初に疑う。じゃあそれかと思ってv1に対応するように変更してもNGだ。どういうこと？ということで迷路に入っていくわけだ。
結論：PyPi ahkは特にGUI周りでほとんど役に立たない
そしてそういう視点でPyPi ahkの実装状況を確認したら、まぁほとんどのGUI操作系は未実装だ。Implementedと書かれていてももう信用しない💢実際の使い方コマンド欄が空白なのだから、信じられないよ。
ってことでahkのPythonラッパーはほとんど役に立たないことが判明😭裏切られた気分だ。（信じた自分が愚かなのだよ……。）
またしても最初に戻ってくる
何の成果も得られませんでした、と。画像は省略w
つまり、最初に付け焼き刃で実装した対処方法が一周回ってベストな対策だったというわけだ。具体的にはahkのソースファイルにPython上で文字列の結合によって、実行時ごとに新たな変数を追加するというアナログな方法で、ソースファイル内のahkソースコードに外部から変数を足すという作戦。.ahk自体がAutoHotkey.exeに渡されるわけではなく、あくまでもPythonソースコード上にahkのソースコードがテキストとして存在しているため、引数渡しはできない。何ともアナログな実装だが、原理を考えたら「元々の文字列扱いとして文字情報を追加・削除・変更」することしかできないわけだ。めっちゃアナログ。まったくデジタルなアプローチじゃないが仕方がない。
とりあえず動いているので今はこれで良しとする。
AutoHotkeyをどうPythonで使っていくか
次に、ahkでボタンUIの動作テスト。ChatGPTに作らせたボタンがこちら。
Python学習者なら誰しもが「これならTkinterでよくね？」と思うだろう。だがTkinterはPython 3.8以降のVerではバグにより最上段の点線、つまりボタンフォーカス、これがない状態からスタートする（指定しても無視されるというバグ）。Tkinterでフォーカスを表示させるためにはユーザーがTABキーを押して初めて現れる。あとTkinterだと矢印キーでフォーカスが動かない。TABキー操作オンリー。さらにEnterキーも使えない。（それらは色々工夫してようやく、矢印キーとEnterキーが使える😱）
それに対してahkではボタン実装のこの状態でいきなり上下左右の矢印キーもTABキーもEnterキーも使える。操作性がスタートからまったく異なる。GUIだからと言って見た目だけがGUIの本質じゃない。操作性こそが重要なのだ。なので質素でもTkinterではなくてahkで実装したいわけよ。ここにこだわる。
何せ私がEnterや矢印キーでGUIボタンを操作したいわけだからw
ただしボタンUIがAutoHotkeyでできているので、そこからの処理はPythonに引き渡す必要がある。.pyや.exeをahk側から呼び出すわけだ。仕組みとしては完全に関数ドリブンのアプリになる。しょうがない。これがフルでPythonならば、例えばPySide6などを使った場合にはイベントドリブンで設計できるがしょうがない。というかZbrush、Zscriptが関数ドリブンなので、結局は都合がいいのか？など今書きながら思った。何にしてもイベントドリブン型のアプリは当面作ることもなさそうだ。
私の記憶ではBlenderのアドオンはほぼイベントドリブンだった気がする。遠い過去の記憶w
結局、ahkで固める領域とPythonで実行する領域にスパッと分割
一周回って結局は、「ここはピュアahkで実装」「ここはPythonで実装」「ここでPythonからahkに変数を渡す」という3択ブロックで設計することになった。期せずして突貫工事の実装に戻った。昨晩の実装から何一つ変える必要がない。結局、何の成果も（略
この「スパッと分割」によってワークフローも見直し。Pythonでの結合テスト中のahk側のバグは、もうスパッと諦めてソースコピペでVS Codeに持ってきてahk専用IDE環境で検証し、OKならまたコピペでPyCharm上の.pyの文字列として上書きコピペという、アナログ作業になった。
.pyファイル上にあるahkソースコード
これが嫌で何とかPyCharm上でできないか、あるいはファイルの指定を変更することでPyCharmとVS Codeとで往復できないか考えたが無駄だった。.pyファイル上にあるahkソース。エディタのハイライト表記が切り替え不能。混ぜるな危険。しかもベースは.pyなので拡張子で切り替わる機能も使えない。
なのでahkをPython上で使うというアナログ手法を採用した結果、両者の編集はテキストコピペで往復というアナログ手法に落ち着いた。貼り付け先の一時ファイルの.pyのPyCharmと、 .ahkのVS Codeとでエディタ・ハイライトを変える作戦（ついでにインタプリンタも変わる）。まったく残念な話だが、これが一番効率的なのだ。
デジタル全盛のプログラミングで、まさかのアナログ工程こそが最短距離とは……。わからんもんだ。
とりあえず外堀完成。ワークフローは固まった
また夜中になった😖でも今日まででほぼ検証作業が終了した。
Pythonとahkの使い分けが決まった
PyCharmとVS Codeの使い分け（コピペ作戦w）
ピュアahk領域が必ず存在することが確定（ボタンUIやGUI操作時）
Pythonからahkへの変数渡し専用の自作関数が必要
ボタンUIはシンプルでもahkで実装
関数ドリブン型アプリ
もうアプリの外枠はほぼ確定だろう。結局ahkに関してはウィンドウGUI操作関連とウィンドウGUIそのものについてはPythonとは別に学ぶ＆実践する必要がある。だがGUIの操作性に難のあるTkinterに習熟するよりは意味があるだろう。GUIのInput, Outputに関してはahkで処理すると決めれば学習モチベはあるわけで。（あと簡単なデスクトップ操作アプリも作れるメリットがある。サクッと作る自分用自動化ツール、RPAツールね。）
GUIについてはもしかしたら数ヶ月後にPySide6を身につけたらそのときにリファクタリングしてもいいだろう。それでもahkのGUI関連の知識はWindow GUI操作に応用できるので無駄にはならない。
とりあえずZbrushから外側の開発環境は整った。あとはZscriptによるZbrush内部の面倒臭い実装が待っている。あぁ面倒臭い。過去の完成済みソースコードを引っ張り出さないといけない。面倒臭い。
今回の創作活動は約1時間30分（累積 約3,864時間）
（1,111回目のnote更新）
何だかゾロ目ですな～😊
いいなと思ったら応援しよう！
