Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

FYI... Should the input processing be in the DLL?

1 view
Skip to first unread message

John Doe

unread,
Dec 16, 2013, 2:41:11 PM12/16/13
to

This is mainly for your information.

You might have discovered it soon anyway. Some people say that you
should not be processing stuff in the DLL, that you should relay the
keystroke information to an EXE. Over the years in various versions I
have had it like that. But it was a clumsily implementation. Since I
don't know how to make message procedures (or whatever you call it),
I just copied and pasted some message stuff that my system probably
doesn't use. It seemed to work, however bad.

Apparently the argument for processing input in an EXE (or whatever)
instead of in the DLL has something to do with not tying up the
process that you're working in. Maybe to do with threads? Anyways...
I have at times in the past noticed some weird delay probably caused
by input processing in the DLL, but I haven't noticed it recently.

Again... Doesn't really matter to me, currently.

Mr. G

unread,
Dec 16, 2013, 10:50:12 PM12/16/13
to
It would be possible to spawn threads to hand off processing to, but
the philosophy I've always read is it's better not to do
multi-threading at all than to do it badly. That's a whole other can
of worms that I suspect neither of us has time for right now, but it's
a thought. Really I'm not convinced that it's even worth doing if one
knew how, but I suppose a little research on processing system hook
callbacks might give a little insight. In my mind, it seems that any
problems that may arise in this regard can be avoided by simply taking
one's time between actions so that we don't get ahead of our code when
recording a macro. And here again, I'm not convinced that it's even a
problem that needs solving, although I'm not discounting the weird
delay problems you experienced. I'm just glad they don't seem to be
happening recently, so maybe it was some other cause altogether.

I reckon if it's working as-is, then that's the important thing. We
could always set a threading expert loose on it later just to see if
it yields any improvements.

Mr. G
0 new messages