ActiveBasic V2のリンクを公開下さい
ActiveBasic V2のリンクを公開下さい
以前下記で、「ActiveBasic V2」がダウンロードできました。
http://www.discover-soft.com/activebasic2.6/
いま、リンク先が見当たらないので、お教え下さい。
LineInput など、N88BASICの互換性は、V2が高いので、是非継続して使いたいのです。
[/url]
http://www.discover-soft.com/activebasic2.6/
いま、リンク先が見当たらないので、お教え下さい。
LineInput など、N88BASICの互換性は、V2が高いので、是非継続して使いたいのです。
[/url]
Re: ActiveBasic V2のリンクを公開下さい
>> LineInput など、N88BASICの互換性は、V2が高いので、是非継続して使いたいのです。
LineInputは、せひとも採用(復活?)させて欲しいですね。
私の場合は、LineInputが使えない事で、VBからの移行が進みません。
ABへ移行したいと思いつつ、不定形のテキストファイルを扱うソフトを作るケースが多い事もあって、どうしてもLineInputのあるVBに落ち着いちゃいます。
公開されているLineInputを利用させてもらって対応する事もありますが、やっぱりできれば標準機能として欲しいです。
LineInputって、採用が見送られてしまうほど、需要が低いものなんしょうかね・・・?
LineInputは、せひとも採用(復活?)させて欲しいですね。
私の場合は、LineInputが使えない事で、VBからの移行が進みません。
ABへ移行したいと思いつつ、不定形のテキストファイルを扱うソフトを作るケースが多い事もあって、どうしてもLineInputのあるVBに落ち着いちゃいます。
公開されているLineInputを利用させてもらって対応する事もありますが、やっぱりできれば標準機能として欲しいです。
LineInputって、採用が見送られてしまうほど、需要が低いものなんしょうかね・・・?
Re: ActiveBasic V2のリンクを公開下さい
> >> LineInput など、N88BASICの互換性は、V2が高いので、是非継続して使いたいのです。
私もいまだにVer.2.xを使わせてもらってますので、
公式サイトでの継続公開を、ぜひしてほしいですね。
> LineInputって、採用が見送られてしまうほど、需要が低いものなんしょうかね・・・?
たぶん、需要はあるんでしょうけども、ABの仕様の関係で採用が見送られたんじゃないかと思っています。
不定形のテキストファイルを扱うゆえに、どのくらいの量が読み込まれるか
わからないですよね。ところが、String型はVer2.xでは16KByte(4KBだったかも?)を
超えるとアプリケーションエラーで落ちたと思います、たしか。
Ver3.xではString型の上限はもっと小さくなっているように思いますので、
それゆえに、すでにライブラリが公開されている現状からは、
わざわざ標準機能として採用はないのではなかろうかと。
私もいまだにVer.2.xを使わせてもらってますので、
公式サイトでの継続公開を、ぜひしてほしいですね。
> LineInputって、採用が見送られてしまうほど、需要が低いものなんしょうかね・・・?
たぶん、需要はあるんでしょうけども、ABの仕様の関係で採用が見送られたんじゃないかと思っています。
不定形のテキストファイルを扱うゆえに、どのくらいの量が読み込まれるか
わからないですよね。ところが、String型はVer2.xでは16KByte(4KBだったかも?)を
超えるとアプリケーションエラーで落ちたと思います、たしか。
Ver3.xではString型の上限はもっと小さくなっているように思いますので、
それゆえに、すでにライブラリが公開されている現状からは、
わざわざ標準機能として採用はないのではなかろうかと。
Re: ActiveBasic V2のリンクを公開下さい
Line Input については,一応代替処理用ライブラリがあるのですが
AB2のLine Inputよりも遅くなってしまうようです。
http://www50.tok2.com/home/losedog2/download.htm#ABLIB (まけイヌさん作)
私も現在試しに,もっと速い方法がないか作ってみてるところですけどね。
AB2のLine Inputよりも遅くなってしまうようです。
http://www50.tok2.com/home/losedog2/download.htm#ABLIB (まけイヌさん作)
私も現在試しに,もっと速い方法がないか作ってみてるところですけどね。
' ============================================================
' Sinryow Game Home Page - http://www.sinryow.net/
' Sinryow ActiveBasic Center - http://ab.sinryow.net/
' ============================================================
' Sinryow Game Home Page - http://www.sinryow.net/
' Sinryow ActiveBasic Center - http://ab.sinryow.net/
' ============================================================
Line Input作ってみました:試案
互換を意識したLineInputを作ってみました。
Input #1, s
などと同様に、Open + Close と共に利用します。
LineInput 1, s
※LineInput (ファイルナンバー), (String型変数)
で使えます。「#1」ではなく「1」と書きます。
もちろん、Input #1, s などと混在しても問題ありません。
Ver3.13 + Win2000 で動作確認。
わざわざWsStrChr()とか定義しているのは、私の好みのせいです(^^;)
行の終端は LF or CR+LF で判断しています。
問題は、
LineInput #1, s
でなく
LineInput 1, s
と#を外して書かなきゃいけないため、Ver2.xのABファイルをそのまま移せないこと。
Inputの定義ファイルを見ると
Macro INPUT_FromFile(FileNumber As Long)
で#が使えているのですが・・・Macroの仕様はよく分かりません。
BackSearchABで「NoWestさんのページに以前書いてあった話で
Macroに関するものが」との記述を見つけましたが、辿れず。
もう消えているのか、見つけられなかっただけか。
ご存知の方いますか?
>> Line Input については,一応代替処理用ライブラリがあるのですが
>> AB2のLine Inputよりも遅くなってしまうようです。
>> http://www50.tok2.com/home/losedog2/download.htm#ABLIB (まけイヌさん作)
まけイヌさんのライブラリは私も以前に使わせてもらいましたが、
ある条件下で、同じ文を二度読み込んで来たり、ファイルの最後まで読み込んでしまったり、
というバグが合ったように思います。
・・・と、言うだけ言っておいて『発生条件不明』なので大変恐縮ですが。
やー、その後String型の文字数上限などの問題から、
BytePtr型+ReadFileで一括読み込みするようになったもので、
エラーの原因究明を放置しちゃってるんですよ。
今となっては、そのエラーが出たファイル自体、何処に行ったか分かりません・・・。
もうバグ修正版がアップされていましたら、ごめんなさい。
>> 私も現在試しに,もっと速い方法がないか作ってみてるところですけどね。
他のスレでも「Ver2.xに比べて遅い」との記述を見かけた気がしますが、
方法次第でもっと速度が上がるものなのですか?
それは考えもしませんでした。
バッファーに読み込んで1Byteずつ順に走査してLFを探していく方法しか、
思いつきませんでした。
上のコードでは、将来的に最初にファイル終端まで読み込んでおいて、
LineInputが呼び出されたら、その読み込んでおいたバッファーから値を
返せば早くなるかな~と、考えて組んでますが、そうすると
Open + Close 文の定義も書き換える必要が出てくるので、
今回はそこまではやっていません。
Input #1, s
などと同様に、Open + Close と共に利用します。
LineInput 1, s
※LineInput (ファイルナンバー), (String型変数)
で使えます。「#1」ではなく「1」と書きます。
もちろん、Input #1, s などと混在しても問題ありません。
コード: 全て選択
'内部関数。
'指定された文字(Byte型)が大文字なら小文字にして返す。
Function __WsByteLower( a As Byte ) As Byte
If( TRUE=IsCharUpper(a) )Then
__WsByteLower = a + 32
Else
__WsByteLower = a
EndIf
EndFunction
'bBaseb文字列の中でSearch文字(Byte型でアスキーコード指定)が最初に現れるポインタを返す。
'無ければNULLを返す。C言語のstrchr()に相当。
' ※上記の__WsByteLower()を利用しています。
Function WsStrChr( pBase As BytePtr, bSearch As Byte ) As BytePtr
dim nBaseSize As Long
dim i As Long
dim j As Long
dim FinishTF As Long
WsStrChr = NULL
nBaseSize = lstrlen( pBase )
i = 0
While( i<nBaseSize-1 )
If( __WsByteLower( GetByte(pBase + i) ) = __WsByteLower( bSearch ) )Then
WsStrChr = pBase + i
ExitWhile
EndIf
i = i + 1
Wend
EndFunction
'LineInputのエミュレート案
Macro LINEINPUT( FileNumber As Long, ByRef strBuffer As String )
Dim poTemp As BytePtr
Dim nReadSize As Long
Dim nFileSize As Long
Dim hFp As Long
Dim nLeftSize As Long
Dim nFpUnitMove As Long
Dim pMark As BytePtr
Dim b As Byte
Dim nShouldGetLength As Long
'パラメータのセット
FileNumber = FileNumber - 1
nFileSize = GetFileSize( _System_hFile[FileNumber], 0 )
hFp = SetFilePointer( _System_hFile[FileNumber], 0, 0, FILE_CURRENT )
nLeftSize = nFileSize - hFp
'一端全て読み込むためのバッファー確保
poTemp = calloc( nLeftSize+1 )
ZeroMemory( poTemp, nLeftSize+1 )
'読み込み
ReadFile( _System_hFile[FileNumber], _
poTemp, _
nLeftSize, _
VarPtr(nReadSize), _
ByVal NULL )
'LFで分割。
pMark = WsStrChr( poTemp, 10 )
If( pMark=NULL )Then
nShouldGetLength = lstrlen( poTemp )
strBuffer = ZeroString( nShouldGetLength + 1 )
strBuffer = lstrcpy( strBuffer, poTemp )
Exit Macro
Else
'引数に代入すべき文字列の長さを得る。
b = GetByte( pMark-1 )
If( b=13 )Then
nShouldGetLength = pMark - poTemp - 1
Else
nShouldGetLength = pMark - poTemp
EndIf
'ファイルポインタの移動先(代入文字列の分だけ進める)を計算。
nFpUnitMove = hFp + ( pMark - poTemp ) + 1
EndIf
'LFの手前までを引数に代入
SetByte( poTemp + nShouldGetLength, 0 )
strBuffer = ZeroString( nShouldGetLength + 1 )
strBuffer = lstrcpy( strBuffer, poTemp )
'ファイルポインタの調整
hFp = SetFilePointer( _System_hFile[FileNumber], nFpUnitMove, 0, FILE_BEGIN )
'バッファー開放
free( poTemp )
End Macro
Ver3.13 + Win2000 で動作確認。
わざわざWsStrChr()とか定義しているのは、私の好みのせいです(^^;)
行の終端は LF or CR+LF で判断しています。
問題は、
LineInput #1, s
でなく
LineInput 1, s
と#を外して書かなきゃいけないため、Ver2.xのABファイルをそのまま移せないこと。
Inputの定義ファイルを見ると
Macro INPUT_FromFile(FileNumber As Long)
で#が使えているのですが・・・Macroの仕様はよく分かりません。
BackSearchABで「NoWestさんのページに以前書いてあった話で
Macroに関するものが」との記述を見つけましたが、辿れず。
もう消えているのか、見つけられなかっただけか。
ご存知の方いますか?
>> Line Input については,一応代替処理用ライブラリがあるのですが
>> AB2のLine Inputよりも遅くなってしまうようです。
>> http://www50.tok2.com/home/losedog2/download.htm#ABLIB (まけイヌさん作)
まけイヌさんのライブラリは私も以前に使わせてもらいましたが、
ある条件下で、同じ文を二度読み込んで来たり、ファイルの最後まで読み込んでしまったり、
というバグが合ったように思います。
・・・と、言うだけ言っておいて『発生条件不明』なので大変恐縮ですが。
やー、その後String型の文字数上限などの問題から、
BytePtr型+ReadFileで一括読み込みするようになったもので、
エラーの原因究明を放置しちゃってるんですよ。
今となっては、そのエラーが出たファイル自体、何処に行ったか分かりません・・・。
もうバグ修正版がアップされていましたら、ごめんなさい。
>> 私も現在試しに,もっと速い方法がないか作ってみてるところですけどね。
他のスレでも「Ver2.xに比べて遅い」との記述を見かけた気がしますが、
方法次第でもっと速度が上がるものなのですか?
それは考えもしませんでした。
バッファーに読み込んで1Byteずつ順に走査してLFを探していく方法しか、
思いつきませんでした。
上のコードでは、将来的に最初にファイル終端まで読み込んでおいて、
LineInputが呼び出されたら、その読み込んでおいたバッファーから値を
返せば早くなるかな~と、考えて組んでますが、そうすると
Open + Close 文の定義も書き換える必要が出てくるので、
今回はそこまではやっていません。
Re: Line Input作ってみました:試案
> >> 私も現在試しに,もっと速い方法がないか作ってみてるところですけどね。
> 他のスレでも「Ver2.xに比べて遅い」との記述を見かけた気がしますが、
> 方法次第でもっと速度が上がるものなのですか?
> それは考えもしませんでした。
> バッファーに読み込んで1Byteずつ順に走査してLFを探していく方法しか、
> 思いつきませんでした。
> 上のコードでは、将来的に最初にファイル終端まで読み込んでおいて、
> LineInputが呼び出されたら、その読み込んでおいたバッファーから値を
> 返せば早くなるかな~と、考えて組んでますが、そうすると
> Open + Close 文の定義も書き換える必要が出てくるので、
> 今回はそこまではやっていません。
まけイヌさんの方法が,「一度バッファにすべて読み込んでしまう」方法ですよ。
それで私も速くなると思ったのですが,それで遅くなるとは・・・。
AB4で以下のコードを試して見ました。
snrmain.phpは9600行・421kbです。
これで52秒かかりました。
※実際はプロジェクトとしており,まけイヌさんのライブラリを入れています
しかし,AB2の以下のコードはわずか3秒(!)で終了します。
仮設としては,バッファから「\r\n」を取り出すための処理が(ABのコンパイラ性能ゆえに)遅いのでは・・・と考えています。
> 他のスレでも「Ver2.xに比べて遅い」との記述を見かけた気がしますが、
> 方法次第でもっと速度が上がるものなのですか?
> それは考えもしませんでした。
> バッファーに読み込んで1Byteずつ順に走査してLFを探していく方法しか、
> 思いつきませんでした。
> 上のコードでは、将来的に最初にファイル終端まで読み込んでおいて、
> LineInputが呼び出されたら、その読み込んでおいたバッファーから値を
> 返せば早くなるかな~と、考えて組んでますが、そうすると
> Open + Close 文の定義も書き換える必要が出てくるので、
> 今回はそこまではやっていません。
まけイヌさんの方法が,「一度バッファにすべて読み込んでしまう」方法ですよ。
それで私も速くなると思ったのですが,それで遅くなるとは・・・。
AB4で以下のコードを試して見ました。
snrmain.phpは9600行・421kbです。
これで52秒かかりました。
※実際はプロジェクトとしており,まけイヌさんのライブラリを入れています
コード: 全て選択
#N88BASIC
' ↓ ここからプログラムが実行されます
Dim fd As Long, buf As String
fd=liOpen("snrmain.php")
Print Time$()
While liGet(fd, buf)>0
Wend
Print Time$()
liClose(fd)
コード: 全て選択
Dim buf As String
Open "snrmain.php" For Input As #1
Print Time$
While Eof(1)=0
Line Input #1, buf
Wend
Print Time$
Close #1
' ============================================================
' Sinryow Game Home Page - http://www.sinryow.net/
' Sinryow ActiveBasic Center - http://ab.sinryow.net/
' ============================================================
' Sinryow Game Home Page - http://www.sinryow.net/
' Sinryow ActiveBasic Center - http://ab.sinryow.net/
' ============================================================
Line Input3種の速度
>> まけイヌさんの方法が,「一度バッファにすべて読み込んでしまう」方法ですよ。
そうですね。
さきほど、最新バージョンのまけ犬さんライブラリをDLして、
以前にエラーを出しただろうファイルでテストしてみたところ、
今回はエラー無く通ったので、問題は修正済みみたいですね。
こちらでも速度計測してみました。
AB3.13で以下のコードで試してみました。
test2.txtは112KB・3177行です。
こちらは9秒かかりました。一方で、
こちらは2秒で済みました。
ちなみにVer2.59の場合は、
1秒で済みました。
確かに速いですが、上記の2秒との差はおそらく、一度バッファーに全て
読み込んでしまうことで、無くせると思います。
ここからは予想なのですが、Ver2.xに比べてVer3.x(or Ver4.x)での
まけイヌさんのLineInputライブラリが遅くなってしまう理由は、
関数内部でMid$を使っているためじゃないか・・・と思ったんですが、
を見てみても、特に遅くなりそうな理由は見つからないですね・・・あれ?
とすると、内部でのIf文の個数でしょうか?
私の場合はLFしか検索してないので、その差かな、と思えなくはないか・・・と。
そうですね。
さきほど、最新バージョンのまけ犬さんライブラリをDLして、
以前にエラーを出しただろうファイルでテストしてみたところ、
今回はエラー無く通ったので、問題は修正済みみたいですね。
こちらでも速度計測してみました。
AB3.13で以下のコードで試してみました。
test2.txtは112KB・3177行です。
コード: 全て選択
'まけイヌさん's ライブラリ 利用
#N88BASIC
#include "linput.sbp"
'■変数宣言
Dim hID As Long '<< ファイルIDを受け取るための変数
Dim s As String '<< 取得した文字列を受け取るための変数
'■■サンプルファイル1
'■ファイルの終端が改行されていないケース。
hID = liOpen("test2.txt") '<< ファイルIDを取得
While liGet( hID, s) '<< FALSEが返るまで1行ずつ文字列を取得
'内容表示
'Print s
Wend
liClose(hID) '<< ファイルIDを解放
Input s
End
コード: 全て選択
' 上記案の自前LineInput
#N88BASIC
#include <WSLib6_LikeStringC.sbp>
Dim s As String
Open "test2.txt" For Input As #1
While (Eof(1)=0)
LineInput 1, s
'Print s
Wend
Close 1
Input s
End
ちなみにVer2.59の場合は、
コード: 全て選択
#strict
Dim s As String
Open "test2.txt" For Input As #1
While (Eof(1)=0)
Line Input #1, s
' Print s
Wend
Close 1
Input s
End
確かに速いですが、上記の2秒との差はおそらく、一度バッファーに全て
読み込んでしまうことで、無くせると思います。
ここからは予想なのですが、Ver2.xに比べてVer3.x(or Ver4.x)での
まけイヌさんのLineInputライブラリが遅くなってしまう理由は、
関数内部でMid$を使っているためじゃないか・・・と思ったんですが、
コード: 全て選択
Function Mid$(buf As String, StartPos As Long)(ReadLength As Long) As String
Dim length As Long
StartPos=StartPos-1
If StartPos<0 Then
'error
'Debug
Exit Function
End If
length=Len(buf)
If length<=StartPos Then Exit Function
If ReadLength=0 Then
ReadLength=length-StartPos
End If
If ReadLength>length-StartPos Then
ReadLength=length-StartPos
End If
Mid$=ZeroString(ReadLength)
memcpy(Mid$,StrPtr(buf)+StartPos,ReadLength)
End Function
とすると、内部でのIf文の個数でしょうか?
私の場合はLFしか検索してないので、その差かな、と思えなくはないか・・・と。
淡幻星さんのコードを改造してみました。
改行コードはCR, LF, CR+LFに対応しています。
実機では処理速度を半分程度に抑えることが出来ました。
ただ、ExcelVBAと処理速度を比べるととても遅いので、
一旦バッファに読み込む方法を取らないと
劇的な速度向上は望めないと思います。
改行コードはCR, LF, CR+LFに対応しています。
実機では処理速度を半分程度に抑えることが出来ました。
コード: 全て選択
Macro LINEINPUT(FileNumber As Long, ByRef strBuffer As String)
Dim Buf As BytePtr
Dim Size As Long
Dim Length As Long
FileNumber = FileNumber - 1
Size = GetFileSize(_System_hFile[FileNumber], 0) - _
SetFilePointer(_System_hFile[FileNumber], 0, NULL, FILE_CURRENT)
Buf = calloc(Size + 1)
ReadFile(_System_hFile[FileNumber], Buf, Size, VarPtr(Size), ByVal NULL)
Length = 0
While TRUE
Select Case Buf[Length]
Case NULL
Exit While
Case 10 'LF
SetFilePointer(_System_hFile[FileNumber], Length + 1 - Size, NULL, FILE_END)
Exit While
Case 13 'CR or CRLF
SetFilePointer(_System_hFile[FileNumber],
Length + 1 - (Buf[Length + 1] = 10) - Size, NULL, FILE_END)
Exit While
Case Else
Length = Length + 1
End Select
Wend
strBuffer = ZeroString(Length)
memcpy(StrPtr(strBuffer), Buf, Length)
free(Buf)
End Macro
一旦バッファに読み込む方法を取らないと
劇的な速度向上は望めないと思います。
この話題、終わっちゃいました?
私の名前が出たのと、淡幻星様と久々にお会い(?)できたのとで
書き込んでみました。
Sinryow様のおっしゃるとおりLine Inputもどきライブラリ「linput.sbp」は
一度ファイル全体をバッファに取り込み、その後順次シークしています。
この方法は素直ではなく、またLine Input命令の動作とも違います。
※コンセプトの中に「あまり考えずに楽に使える」というのもあったので、
この仕様になっているというのもあります
※弱点は2GB以上のファイルではliOpen関数が失敗する点です
正確に再現するなら、やはりファイルをロックした状態のまま、
1バイトずつ評価していく地道な方法になります。
..が、これをActiveBasic側でやっていては、
どう頑張ってもLine Inputの処理速度を越える事は出来なさそうです。
一応、現在LDGDI自体をクラスライブラリ化していますが、
実はこの中でLine Inputみたいな機能を実現しています。
コードはほぼ同じなのですが、何故かクラス化する事で多少速くなるみたいです。
※メンバ変数へのアクセス速度が優位に出来ているのかな??
P.S.
しかし、プログラムの速度アップの話題は心なしかウキウキしますね♪
早く上記ライブラリのバグを潰してしまおう..(苦笑)
書き込んでみました。
Sinryow様のおっしゃるとおりLine Inputもどきライブラリ「linput.sbp」は
一度ファイル全体をバッファに取り込み、その後順次シークしています。
この方法は素直ではなく、またLine Input命令の動作とも違います。
※コンセプトの中に「あまり考えずに楽に使える」というのもあったので、
この仕様になっているというのもあります
※弱点は2GB以上のファイルではliOpen関数が失敗する点です
正確に再現するなら、やはりファイルをロックした状態のまま、
1バイトずつ評価していく地道な方法になります。
..が、これをActiveBasic側でやっていては、
どう頑張ってもLine Inputの処理速度を越える事は出来なさそうです。
一応、現在LDGDI自体をクラスライブラリ化していますが、
実はこの中でLine Inputみたいな機能を実現しています。
コードはほぼ同じなのですが、何故かクラス化する事で多少速くなるみたいです。
※メンバ変数へのアクセス速度が優位に出来ているのかな??
P.S.
しかし、プログラムの速度アップの話題は心なしかウキウキしますね♪
早く上記ライブラリのバグを潰してしまおう..(苦笑)
「実践コードモジュール」へ掲載しては?
久しぶりに覗きに来たら、なにやらLINE INPUTの話題が上がっていますね。
コードの掲載や、それに対する修正案などもあり、このまま掲示板の中に埋もれてしまうとすごく勿体無いような気が・・・
こういのって、「実践コードモジュール」の格好のネタになるのでは?
#・・ていうか、掲載希望(笑)
コードの掲載や、それに対する修正案などもあり、このまま掲示板の中に埋もれてしまうとすごく勿体無いような気が・・・
こういのって、「実践コードモジュール」の格好のネタになるのでは?
#・・ていうか、掲載希望(笑)
≫高信期様、まけイヌ様、KAMATY様
えー、しばらく空けてのレスなので、ご覧になられるか分かりませんが、主に上記の御三方へ。では、順に。
≫高信期さん
ここへの投稿の後、Ver2.xのエミュレート関数ライブラリとして、
調子に乗って自分のサイトでLineInputを公開し始めたのですが、
そちらの次回更新版に、高信期さんのコードを利用させて頂いて
よろしいでしょうか?
いえ、随分とすっきりとスマートに書かれているな~と思いまして。
それから、「BytePtr型+ReadFileで一括読み込みしたほうが操作早い&楽~」
などと宣いましたが、それはあくまでしっかりソフトを作りこむときであって、
ちょっとコードを組む、一回使ったら破棄、程度に軽く作るときは、
String型+Openを利用した方が随分と楽だと、さきほど思い直したのも理由です。
そんなわけで利用させていただきたいのですが、よろしいでしょうか?
もしよろしければ、その後「実践コードモジュール」へも
転載させていただこうかと思います。
私を含め、Ver2.x好みにとってはOpen命令と共にVer3.xで使えることは、
有用なポイントだと思いますので。
≫まけイヌさん
一時期ちょっと顔を出しただけで、しばらく音沙汰の無かった私を
覚えていてくださいましたか。びっくりしました。光栄です。
この後の話題は、ここの掲示板の趣旨から外れますので、まけイヌさんの
サイトにお邪魔させていただこうかと思います。続きはそちらで。
≫KAMATYさん
そんなわけで(上記参照)、しばらく経ちましたけれども、
「実践コードモジュール」への転載も無いようですので、
もし高信期さんの許可が下りましたら、差し出がましいですが、
私が高信期さんのコードを転載させていただこうかと思います。
私のよりも高信期さんのコードの方がよっぽど綺麗ですので。
ついでにClipStr、SetClipStrのエミュレート案も載せようかと思ってます。
クラス化されたそれが既にあるようですが、Ver3.xではまだ使えませんし。
うーむ。Ver4.xはまだバグや仕様変更の危険性があるので、
クラスが魅力的にしろ未だにVer3.xを利用している私や、
N88Basicとの互換性がより優れている(≒命令簡単)Ver2.xを好む私などは、
少数派なんでしょうかねぇ?
Ver2.xのリンクが復活しないところを見ると、山本様としては、
早くユーザーにVer4.xに移行して欲しく思っているように感じます。
逆行してスイマセン。>山本様
≫高信期さん
ここへの投稿の後、Ver2.xのエミュレート関数ライブラリとして、
調子に乗って自分のサイトでLineInputを公開し始めたのですが、
そちらの次回更新版に、高信期さんのコードを利用させて頂いて
よろしいでしょうか?
いえ、随分とすっきりとスマートに書かれているな~と思いまして。
それから、「BytePtr型+ReadFileで一括読み込みしたほうが操作早い&楽~」
などと宣いましたが、それはあくまでしっかりソフトを作りこむときであって、
ちょっとコードを組む、一回使ったら破棄、程度に軽く作るときは、
String型+Openを利用した方が随分と楽だと、さきほど思い直したのも理由です。
そんなわけで利用させていただきたいのですが、よろしいでしょうか?
もしよろしければ、その後「実践コードモジュール」へも
転載させていただこうかと思います。
私を含め、Ver2.x好みにとってはOpen命令と共にVer3.xで使えることは、
有用なポイントだと思いますので。
≫まけイヌさん
一時期ちょっと顔を出しただけで、しばらく音沙汰の無かった私を
覚えていてくださいましたか。びっくりしました。光栄です。
この後の話題は、ここの掲示板の趣旨から外れますので、まけイヌさんの
サイトにお邪魔させていただこうかと思います。続きはそちらで。
≫KAMATYさん
そんなわけで(上記参照)、しばらく経ちましたけれども、
「実践コードモジュール」への転載も無いようですので、
もし高信期さんの許可が下りましたら、差し出がましいですが、
私が高信期さんのコードを転載させていただこうかと思います。
私のよりも高信期さんのコードの方がよっぽど綺麗ですので。
ついでにClipStr、SetClipStrのエミュレート案も載せようかと思ってます。
クラス化されたそれが既にあるようですが、Ver3.xではまだ使えませんし。
うーむ。Ver4.xはまだバグや仕様変更の危険性があるので、
クラスが魅力的にしろ未だにVer3.xを利用している私や、
N88Basicとの互換性がより優れている(≒命令簡単)Ver2.xを好む私などは、
少数派なんでしょうかねぇ?
Ver2.xのリンクが復活しないところを見ると、山本様としては、
早くユーザーにVer4.xに移行して欲しく思っているように感じます。
逆行してスイマセン。>山本様