time = new Date();
Editor.SetDrawSwitch(0)
for(line = 0; line < 100; line++){
	for(i = 0; i < 1000; i++){
		Editor.InsText("a");
	}
	Editor.InsText("\r\n");
}
Editor.SetDrawSwitch(1);
Editor.Redraw();
last = new Date();
Editor.InsText(last - time);

▼ ななしさん

言いたいことはなんとなく分かりました。
ぼくはマクロの実行速度なんて捨てちゃえ、と言いましたが、
事務用スペックの端末でこれを実行したら酷いことになりそうですね。

まぁ、ここまでのマクロを組める人なら、
この処理が実用的じゃないことは分かると思います。
同じことを1秒未満で完了させるスクリクプティング手法は、
他にいくらでもあります。

やりたいことを実現するのに最適な手段を選択できることも、
ある種のITスキルだと思います。


追記
投稿されたマクロの実行時間。
ver.2.1.1.4+ (rev3870) 26015ミリ秒
ver.2.1.1.4+ (rev3873)  9695ミリ秒

投稿マクロが遅い原因に対策した版での実行時間。
ver.2.1.1.4+ (rev3870)   105ミリ秒
ver.2.1.1.4+ (rev3873)   112ミリ秒

やはり、サクラエディタ側で対策する必要なんてない気がします。

いつも使わせてもらってます。

Win7 32bit でver2.3.2.0 Unicode版を使っていますが、
たまに落ちるので、デバッグ版をコンパイルして
再現するまで起動／終了を繰り返しました。
すると、必ず

sakura_core/util/shell.cpp 内119行の
SHGetSpecialFolderLocation()

で失敗します。

どうやら正しく解放できていないかと思われますが
他の方は、いかがでしょうか？おま環なのかもしれません。

ちなみにこの関数はもうサポートされないそうで
いずれは SHGetFolderLocation() に代わらないといけないようですが

https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb762203(v=vs.85).aspx

ANSIとコードが共有ならば DllGetVersion() で判定するしかないですかね？。

https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb776779(v=vs.85).aspx

▼ hagiさん
> ...
> 
> ANSIとコードが共有ならば DllGetVersion() で判定するしかないですかね？。
> 
> ...
こーどは  きょうゆう  して  おりま   せん

> こーどは  きょうゆう  して  おりま   せん

↓
http://svn.code.sf.net/p/sakura-editor/code/sakura/trunk
↑-これ  とは

こんばんは。

▼ hagiさん
> すると、必ず
> 
> sakura_core/util/shell.cpp 内119行の
> SHGetSpecialFolderLocation()
> 
> で失敗します。

64bit版windowsで試した限り再現しませんでした。
具体的にどうなって落ちる（デバッグブレークする）かまで書いていただけると、
より意味のあるレスを返すことができるような気がします。たぶん。

単に想像ですが、メモリ解放周りのコードがおかしい気がします。
CRTでいうところの「ヒープが壊れています。」的なエラーがでて止まったのでは？

そして、同ファイル内112行目の変数型が怪しいな、と。
https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb762190(v=vs.85).aspx

In its place, programs can call the equivalent (and easier to use) CoTaskMemAlloc and CoTaskMemFree.


121行目の呼出し結果によらず、
122行目で解放に行ってるあたり。
確保できてないのに解放したから
再確保しようとした瞬間に落ちる、と。


該当コードはv2専用なので
windows2000で動作できる関数ならば使ってよい認識です。

▼ hagiさん
> ちなみにこの関数はもうサポートされないそうで
> いずれは SHGetFolderLocation() に代わらないといけないようですが

https://sourceforge.net/p/sakura-editor/patchunicode/1107/
patch登録しました。

▼ noviceさん
> ▼ hagiさん
> > ちなみにこの関数はもうサポートされないそうで
> > いずれは SHGetFolderLocation() に代わらないといけないようですが
> 
> https://sourceforge.net/p/sakura-editor/patchunicode/1107/
> patch登録しました。

これって問題が解決した、ってことでいいんですか？

32bit版のライセンスは持っていないから、
うちでは再現確認ができないので、
情報があればあげていただけるとありがたいです。

それ以前の問題として、サクラの定義をよく見てみると、数か所間違いがあるようにみえます。
defineのほうはrev:3680以降からです。
こうじゃないでしょうか。

Index: sakura_core/util/string_ex.h
===================================================================
--- sakura_core/util/string_ex.h	(リビジョン 4157)
+++ sakura_core/util/string_ex.h	(作業コピー)
@@ -253,9 +253,9 @@
 
 //印字系
 #if defined(_MSC_VER) && _MSC_VER>=1400
-#define auto_snprintf_s(buf, count, format, ...) tchar_sprintf_s((buf), count, (format), __VA_ARGS__)
+#define auto_snprintf_s(buf, count, format, ...) tchar_snprintf_s((buf), count, (format), __VA_ARGS__)
 #define auto_sprintf(buf, format, ...)           tchar_sprintf((buf), (format), __VA_ARGS__)
-#define auto_sprintf_s(buf, nBufCount, format, ...) tchar_snprintf_s((buf), nBufCount, (format), __VA_ARGS__)
+#define auto_sprintf_s(buf, nBufCount, format, ...) tchar_sprintf_s((buf), nBufCount, (format), __VA_ARGS__)
 #else
(すみません省略します)
Index: sakura_core/util/tchar_printf.cpp
===================================================================
--- sakura_core/util/tchar_printf.cpp	(リビジョン 4157)
+++ sakura_core/util/tchar_printf.cpp	(作業コピー)
@@ -359,6 +359,7 @@
 
 
 // sprintf_sラップ
+// ※nBufCountをはみ出す場合は異常終了します。
 //
 // (実装について)
 //     内容が同じなので、templateでも良かったのですが、
@@ -418,7 +419,7 @@
 {
 	va_list v;
 	va_start(v,format);
-	int ret=tchar_vsprintf_s(buf,count,format,v);
+	int ret=tchar_vsnprintf_s(buf,count,format,v);
 	va_end(v);
 	return ret;
 }
@@ -426,7 +427,7 @@
 {
 	va_list v;
 	va_start(v,format);
-	int ret=tchar_vsprintf_s(buf,count,format,v);
+	int ret=tchar_vsnprintf_s(buf,count,format,v);
 	va_end(v);
 	return ret;
 }

▼ もかさん
> それ以前の問題として、サクラの定義をよく見てみると、数か所間違いがあるようにみえます。
> defineのほうはrev:3680以降からです。

やっと言ってる意味が分かりました。
わたしの修正コードでなくて、
現在のコードに対する修正提案なんですね。


(tchar_snprintf_sの実装部分)
> -	int ret=tchar_vsprintf_s(buf,count,format,v);
> +	int ret=tchar_vsnprintf_s(buf,count,format,v);

コア実装がいまのままなら同じことなんで
間違っていても機能的には影響ないと思います。

機能的に影響がなければ直さない、
それが乙女のポリシー。

と言われたらもう何も言えねっす。


ちなみに、tchar_snprintf_sは直呼びじゃなく
auto_snprintf_sを経由するのが正道と思われます。

string_ex.h 260行目
inline int auto_snprintf_s(ACHAR* buf, size_t count, const ACHAR* format, ...)   { va_list v; va_start(v,format); int ret=tchar_vsnprintf_s(buf,count,format,v); va_end(v); return ret; }
inline int auto_snprintf_s(WCHAR* buf, size_t count, const WCHAR* format, ...)   { va_list v; va_start(v,format); int ret=tchar_vsnprintf_s(buf,count,format,v); va_end(v); return ret; }
inline int auto_sprintf(ACHAR* buf, const ACHAR* format, ...)                    { va_list v; va_start(v,format); int ret=tchar_vsprintf(buf,format,v); va_end(v); return ret; }
inline int auto_sprintf(WCHAR* buf, const WCHAR* format, ...)                    { va_list v; va_start(v,format); int ret=tchar_vsprintf(buf,format,v); va_end(v); return ret; }
inline int auto_sprintf_s(ACHAR* buf, size_t nBufCount, const ACHAR* format, ...){ va_list v; va_start(v,format); int ret=tchar_vsprintf_s(buf,nBufCount,format,v); va_end(v); return ret; }
inline int auto_sprintf_s(WCHAR* buf, size_t nBufCount, const WCHAR* format, ...){ va_list v; va_start(v,format); int ret=tchar_vsprintf_s(buf,nBufCount,format,v); va_end(v); return ret; }

こっちは合ってますな。

内部実装のva_arg版関数を呼び出すだけの代物なので、
呼び出し口で１か所対応すれば目的を果たせるはずです。
邪道を利用してる箇所は非常に少なかったはずなので、
呼出し側を修正して関数定義ごと削除するのが適切かと思います。

関数定義ごと削除してしまえば
誤って利用してしまうことの再発防止にもなりますし。

また、全く同じ意味の実体が別定義で存在するので
機能を損なうこともありません。


まぁ、機能的影響はゼロなので、
どうでもいいっちゃどうでもいい話。