Can you expand on this?
Even if you set your thread to the idle class, it's still going to run at
maximum speed if there are no other threads wanting the CPU.
--
Tim Robinson
http://www.themoebius.org.uk/
>| Why not have "slow/medium/fast" settings and use
>| SetThreadPriority(...BELOW_NORMAL/NORMAL/ABOVE_NORMAL)?
>Can you expand on this?
As a novice programmer.
>Even if you set your thread to the idle class, it's still going to run at
>maximum speed if there are no other threads wanting the CPU.
If you include Sleep(1) or whatever in all of the lowest level
functions I guess, when the playback sends a script fragment which
requires processing, wont the system wait before returning? And that
wait depends on the SetThreadPriority() level? Maybe it just works
when sending single elements in seperate SendInput() functions.
http://home.satx.rr.com/lfolder/hookDLL.cpp
If that helps provide proportional timing without tedious editing,
especially like when task switching, that would be great (for me). No
more editing every stupid macro after recording. For a proof, I just
recorded this in my editor language.
//start macro
_key(_macro_started_,down); <--tell the hook to stop looking
for input
//
_key(_control_,down);
__type(_A_);
_key(_control_,up); <--select all
_key(_control_,down);
__type(_C_);
_key(_control_,up); <--copy
_key(_alt_,down);
__type(_tab_);
_key(_alt_,up); <--switch to WordPad
_key(_control_,down);
__type(_A_);
_key(_control_,up); <--select all
_key(_control_,down);
__type(_V_);
_key(_control_,up); <--paste
_key(_control_,down);
__type(_S_);
_key(_control_,up); <--save
_key(_alt_,down);
__type(_tab_);
_key(_alt_,up); <--switch back to Agent newsreader
//stop macro
_key(_macro_stopped_,down); <--tell the hook to start
looking for input
Set Priority to IDLE and it did go very fast. I just put a heavy
strain on my system, CPU usage is at 46% constant. The playback was
still very fast but performed perfectly again. Since it went so fast
without failing, I cannot say for sure that IDLE helped in that case
but AFAIK other macroers cannot do that without extra timing. If that
is wrong, point me to the demo and I will try it. I just added my
text-to-speech playback while doing another test, performed perfectly
again including the file save in WordPad before returning, except this
time with a stutter. In my experience, commercial program generated
macros of any complexity typically fail without added timing even when
not task switching (unless the user wants to record in real time which
replays very slowly and usually requires editing anyway). Those
timing concerns probably are why commercial macroers include so many
different forms of timing commands. There are macroers which have a
slider for slow/fast which is useful but that probably is not based on
SetThreadPriority() and the slider slows text input as much as file
saves and other major tasks, not proportional or based on system
activity, which makes a speed setting slider almost useless IMO.
Editing macros for timing was a royal pain in the rear. Was. Maybe
someone else can provide other proof right or wrong. Once I get my
version done (after learning enough about programming), I will have
rock solid proof since I constantly use macroers.
LShaping