弐条海月の とはずがたり

そこはかとなく書き綴るブログなるもの

HSPアプリの開発…

昨日に引き続き、Windowsで動作するインタプリタ型のプログラム言語「HSP(Hot Soup Processor)」のお話。新たに開発することになったテキストデータの整形プログラムですが、データベースから書き出されたテキストデータを解析し、コンテンツごとに配列変数に入れ、中身を解析してタグ付けするところまで完成しました。いよいよGUIを作っていくわけですが、HSPはGUI作成がちょっと面倒なところがあるんですよね。そんなお話。

視覚的にオブジェクトを配置していく機能がないので、オブジェクト配置の命令を書いては、実行して結果を確認。数値を変えて位置を微調整する…その繰り返しになってしまいます。救いはインタプリタ型言語なのでコンパイルに時間がかからないこと。だから我慢できますね(笑)。純正ではないビジュアル・エディター的なものがなくもないのだけれど…かつて使ったものは便利とは言えないものだったので諦めております。

HSPのバージョンを3.3にしてから、今まで使っていた外部プラグインが使えなくなってしまったので純正のプラグインのみを使うようにしており、拡張オブジェクトの取り扱いを最初から勉強しなおしているのです。だから時間がかかる(汗)。5月から公開するWEBコンテンツを作るためのプログラムなので、なんとか今週中に試作品を完成させたいと思っております。


HSPでUTF8を扱う…

Windowsで動作するインタプリタ型のプログラム言語「HSP(Hot Soup Processor)」にて急きょ、プログラムを開発することになりました。会社のWEBサイトで公開しているデータベース内のテキストデータを、テーマとおおよその年月日で抽出する必要がありまして。社内サーバーのテキストデータを扱うなら私ひとりでできるのだけれど、その場合はWEB掲載用の整形やら画像処理も発生します。だったら、すでにWEB上にある自社のデータを二次利用すれば余計な手間はかからない…と思い、WEB上での処理は氷翠さんにお願いしました。

氷翠さんは仕事が速いので半日で目的のプログラムを作ってくれました。データは検索したテーマごとにテキストファイル化されております。私のほうではいくつかのテキストファイルを1つに結合し、中身を整形。その後で削除するデータか残すデータかどうかを判断、最後にタグ付けしてhtml化する…そんなアプリを作る計画なのです。

ところが、書き出されてくるテキストファイルは文字コードがUTF8。このままではHSPで扱うことができません。エディタで変換をかけようにも、そのままでは化けしてしまう文字があったりするのです。

どうしたものかなぁと思っていたら、新しいHSPにて文字コードが相互変換できるようになっているのを見つけました。そこでFTPなどネット関係の拡張命令を含む純正のプラグイン「hspinet.as」をインクルード。この中に文字コードに関するものがありまして…「nkfcnv」命令ですね。おかげで長年の問題であったUTF8のテキストファイルをHSPで扱うことが簡単にできるようになりました。私がHSPで文字処理を始めたころは、できなかったはず。だからないものとばかり思っておりました。先入観が仇になったわけです。それにしても、いつからUTF8が扱えるようになっていたんだろう? もっと速く気付けば良かったです。

一番大きな問題が解決したので、あとは急ピッチで開発を進めていこうと思います。


HSPのスプリットウィンドウ…

Windowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」をUbuntu上の「Wine」にて動かす際にネックになるのがヘルプビューワが動作しない問題です。これはブラウザベースであることが原因のため、ブラウザに依存しないヘルプビューワを自分で開発することにしました。アプリ名は「H2Viewer」にする予定。どうせなら検索機能を強化して使い勝手のよいものにするつもりです。そんな中、左側の命令リストと右側のリファレンス表示エリアのサイズを自由に変更できるようにするため、スプリットウィンドウを実装しようと思ったのだけれど…なかなかうまくいかず大変でした。ようやく自分なりに理解しウィンドウのサイズ変更が自由にできるようになりました。完成まではまだまだ時間がかかりますけれども、頑張ろうと思います。本当はスプリットウィンドウの概念とか仕様とか、サンプルソースが難しくて自分で書き直してようやく理解できた話などを書いていたのだけれど、その文章が消失してしまいました(泣)。書き直すエネルギーが残っていないので、ここまでにとどめておきます。うん、実に残念。


テキスト整形アプリ完成…

2種類のテキストを自動判別し整形処理をしてくれるアプリケーションをWindowsで動作するインタプリタガタプログラム言語「HSP(Hot Soup Processor)」にて開発しております。β版が完成したため、Ubuntu上のWineで動作させようと思ってテストをすると起動せず。いや正確には起動はするのだけれど、目的のテキストファイルをドラッグ&ドロップした途端にアプリケーションがストンと落ちるのです。それを解消するお話。

ドラッグ&ドロップ機能の実装は「llmod3」と「dragdrop.hsp」によるものです。Windows上では、当たり前ですが問題なく動作しますから、Wine上のWindows APIとの相性がよろしくないのでしょう。

サードパーティー製の外部プラグインは使わずに開発を進めることに決めた以上、ドラッグ&ドロップ機能は諦めることにしました。代わりに考えたのが所定のフォルダ内にあらかじめテキストファイルを入れてからアプリケーションを起動する方法。これならば実はドラッグ&ドロップよりも処理が簡単ですし、扱いやすいのではないかと思ったのです。

で、アプリと同一階層に処理用のフォルダを作成しました。もしそのフォルダを消してしまった時に自動生成する機能なんかも設けたりしてエラーチェックも万全。これで完成か…と思いきや専用フォルダを設けるよりも、アプリケーションの場所に直接テキストファイルを置いたほうがより簡単だなぁと思ったので、せっかくの機能ですが封印。アプリと同一階層にテキストファイルを置けば、自動認識してファイルを読み込み、2種類の処理のうちどちらの処理が必要がも自動判断する仕様にしました。

で、ちょっと使ってもらったあとで、さらに改良。データの書き出し順序を変更してその後の処理をしやすくしたほか、別の原稿用紙に簡単に貼り付けられるように、クリップボードにコピーするボタンを設けました。

ほかにテキスト書き出し機能もつけようか…とも思いましたが、それはこのアプリをしばらくT女史に使ってもらってから考えようと思います。


テキスト整形アプリの開発…

約1ヵ月の間、ヘルプで週3回のテキスト整形処理のお仕事を手伝っておりました。3回のテキストはそれぞれに似ているようで内容が異なっており、手作業だとかなり面倒です。ですのでお得意のテキスト整形処理アプリをWindowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」にて開発することにしました。その記録です。

まずは1つ目のテキストアプリ開発について。こちらは3月初めに開発したのだけれど「よし!つくる!」と思い立って半日で完成しました(笑)。なぜならば、とりあえず今は自分しか使わないのでGUIが不要。エラーチェックもバグ回避も何もせず、ただ単にダーッと書いたいわばプログラムと言うより単なるバッチ処理のファイルだからです(笑)。

このアプリでは起動するとファイル選択ダイアログが出るので、任意のテキストファイルを選択。すると中身をロードし整形。具体的にはタブを取ったり数字を○付き数字にしたり、名前をカギかっこでくくったりなどの処理を行い、テキストをコピーできるように表示して処理終了…そんな感じのアプリになりました。うん、やはりバッチ処理ですね(笑)。とは言え、自作の文字処理モジュール「kurage_mod」(http://tohazugatari.com/kurage_mod)がなければ簡単にはいかなかったはずです。うーん激しく自画自賛ですが、かゆいところに手がとどくモジュールだなぁ。あ、自分のために自分で作ったので便利なのは当たり前ですがっ(笑)。

さて話を戻して…。速攻で完成したアプリですが…処理せねばならないのは取り引き先から送られてくるテキストのため微妙に中身が異なる場合がありまして。ここから先、精度の高いアプリを作るには、いささか送信されたデータが不足していたんですよね。なのでデータをもっと集めるか精度が高まるよう作り直すかしなければならなさそうです。

もう1つのテキストファイルの処理は、こちらはプログラムで書き出されたテキストの整形なので、とてもラク。だから後回しです(笑)。また、もうひとつはFAXで送られてくるのを手打ちしなければならないので、こちらは処理不要ですね。

ということで、処理する必要があるのは2種類のテキストファイル。2つのアプリケーションを作って使い分けても良いのだけれど、自分以外の人が使うとなれば…できるだけ簡単に扱えるようにしたくなるじゃないですか。今回のアプリは後でT女史に使ってもらうものなので、できるだけ簡単に動作するほうがいい。さらに言えば、処理するテキストファイルを選択ダイアログで選ぶのではなく、ドラッグ&ドロップで動作し自動でどちらのテキストファイルの整形処理を行うのか判断するアプリケーションがよいですね。

いざ開発…。まずはドラッグ&ドロップの処理からです。こちらは以前使っていた外部プラグインを使わないようにしているため「llmod3」を利用します。ドラッグ&ドロップの処理はとても簡単でした。まずは「#include」命令で「llmod3」の本体である「llmod3.hsp」と、ドラッグ&ドロップを実現するためのモジュール「dragdrop.hsp」を呼び出します。

次にドラッグ&ドロップされたファイル名を格納する変数とファイル数を格納する変数を用意。後は「dd_accept」を書くだけ。この命令はパラメーターを3つ持っており、書式は「dd_accept p1,p2,p3」です。p1にはファイル名を格納する変数、p2にはファイル数を格納する変数、p3には対象となるWIN_IDを入れます。p3は省略するとデフォルトのID=0が選ばれます。ただしID=1は選択できません。

ドラッグ&ドロップのチェックは、「goto」命令でループを作り出し、ファイル数を格納する変数の変化を調べることで実現しています。私の例を挙げるとこんな感じになっています。

	#include "llmod3\\llmod3.hsp"
	#include "llmod3\\dragdrop.hsp"				
//ドラッグ&ドロップのため
	DRAG_TMP=""	;ドラッグ&ドロップされたファイル名を入れる変数
	KAZU=0		;ドラッグ&ドロップされたファイル数を入れる変数

	//ドラッグ&ドロップ命令(p1=ファイル名、p2=ファイル数、p3=対象WIN_ID)
	dd_accept DRAG_TMP,KAZU,0

*DRAG_WAIT
	wait 1
	if KAZU!0 {		//ドラッグ&ドロップされたら以下
の処理

	}

	goto *DRAG_WAIT

まずは面倒なほうの整形処理から始めております。結局、精度を高めるために当初の概念を捨て去り、最初から書き直すことにしました。固定観念を持つと進歩しないです。できるだけ柔軟な姿勢を保つことが大切ですからね。今回のアプリはテストも含め週末までに完成させるつもりです。


固定ページ

最近の投稿

カテゴリー





カレンダー

2024年5月
 12345
6789101112
13141516171819
20212223242526
2728293031  

過去の日記はこちら

キーワードで検索