>> I would welcome ideas for other simple facilities to include. It >> was a > <> > 1) Please let the macro file be human-readable rather than a binary > dump. Easy to hand alter and debug! Should be easy enough - just have text equivalents to the keycodes, e.g. 232 represented by F1, 10 by "ENTER" etc and converted back to ASCII codes again to stuff to the program. > > 2) Next version to include mouse-clicks too, eh ;-) I can think of > ways to read them, but not to stuff them back into the inter-face. In some cases they are represented by ASCII 1 and 2 (e.g. by MKEY%), not actually tried stuffing these codes though to see if these would work, though this was meant for keyboard control, since you couldn't drive the mouse to select a specific loose item or whatever.
> Regarding the other side of your project: what to do once youve > recorded the data, I wrote a keyword that stuffs the keyboard queue. > The syntax for STUFF is: > > STUFF -timeout% | code% | string$ [, -timeout% | code% | > string$ ] * (optionally repeated) > > where: > -timeout% is a negative integer from -1..-32k frames > code% is a character code from 0..255 > string$ is a qstring > > It uses legal traps and is supposed not to get confused by you > changing keyboard queue midways.. You can find a copy on my website > under Programs/Utilities/LX2. The zip file contains the STUFF_bin > toolkit. Let me know if you can use it, with or without some > modification. Ah, this sounds like it might be useful. Must admit I hadn't thought too much about this yet - was more concerned about how to record the keypresses which seemed a much bigger problem until Duncan's suggestion came along. -- Dilwyn Jones _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
