Luc The Perverse wrote:
[me:]
I am not sure if you are insulting me here
Not in the least! I was crediting you with good sense.
I worked for 3 years as a C++ programmer doing windows shite. I didn't
really understand it then either.
That can be nasty: if the pressure is on to "do the work" without ever really
having time to develop an understanding what you are doing, then programming
becomes a confusing and distasteful activity[*]. If you are /also/ working via
MS's God-awful programming tools, then it must be even worse. Add to that the
poor (mostly for historical reasons, I think) design of the MS APIs, then life
must be tough, indeed...
([*] I've been in that position a couple of times and absolutely /hated/ it.)
I'm not much of a Windows programmer myself (I do know a bit, but I'm not
fluent), so any advice I can offer is necessarily suspect. But, FWIW, if you
do decide to re-attack Windows programming at the Win32 level, then I suggest
you start with the elementary stuff ("elementary" in the mathematical sense).
Get hold of a copy of Petzold, and learn what's going on at the message-loop
level; totally ignoring MFC and anything and everything that MS's tools try to
provide for you.
The irony is that if I knew how to plug with a hotkey program I would
probably know how to write the hotkey program to begin with.
<nods/> Or you'd be in a position where you could fairly easily learn how to
do so.
I would love to RTFM - but I need something in tutorial format because I
cannot decipher the individual pages when I encounter them. I am sure
that using an alternate compiler such as mingw would be great if I
understood the underlying principals of windows messaging and the like.
<nods again/> As far as I know, /nothing/ supplied by MS will help here. It
is all either aimed at people who already understand the general terrain (and
who only need to fill in the details of some specific API, or deep nitty-gritty
stuff about the architecture), or is aimed at beginners. The problem is that
when MS write stuff for beginners they nearly always assume that the beginner
will want to make maximum use of the tools' damnable "ease of use" features and
never even /try/ to understand what's going on -- which completely shuts you
out from learning anything useful. Catch 22.
I found Petzold's book very helpful in filling in the foundations. (Short
review: Basically very good. Explains everything that should be explained. It
has far too many long examples for my personal taste (I don't want or need to
read pages and pages of C code), but, of course, some people /love/ examples.
It has rather an old-fashioned feel, and doesn't cover much of the new stuff,
but that's OK (IMO) because it isn't intended to be a /reference/ work (MSDN is
pretty good at that) and shouldn't be treated as one.)
I realize that for exceptionally simple GUIs and programs like I am
working with, I could simply run a java "server" and communicate with a C
gui via UDP packets.
If you are committed to a no-compromise architecture (which I can respect),
then I would /still/ suggest avoiding JNI. I would use two processes, both
long-lived: one would be a Windows program that hooked the keyboard and watched
for hotkeys, the other would be the main Java program (or programs). The two
would communicate over TCP/IP (or perhaps UDP/IP, but I think I'd prefer TCP
for this) Hooking Windows keyboard events seems to be pretty arcane, but from
what I can tell from sniffing around the net, the best method is by using
SetWindowsHookEx(WH_KEYBOARD_HOOK_LL). That, as I understand it, doesn't
require the strange DLL stuff (nor the even stranger architectural reason for
that requirement -- that Windows will map your hook code into the address space
of every target process !). However it does require a standalone Windows event
loop. You /can/ create one of those in JNI, by forking a new thread to run the
loop, but in the end you'd end up with almost exactly the same architecture --
two independent processing loops communicating via some form of IPC -- but
expressed in a significantly more awkward way. Also the two-processes approach
would make it a lot easier to develop/debug the hook program separately from
the main Java code (remember that any fault in that will probably require a
hard reboot to fix).
I suppose, and I hate to say this, that I am probably just not a very good
programmer. Too bad, too bad - when I was hoping that could be my life.
You might be right, but I don't see any reason to suppose that you are. Judge
yourself by what you can learn, and by how well you learn it, when you are in a
/position/ to learn. Getting stuck in "copy paste" land on an ugly C/Windows
project does not count as such. In fact it doesn't count as anything much,
except a few wasted years and some Good Stuff to put in your CV.
If you can compile a hello world program in C, using MS or anyone else's
compiler, and have the right book handy, then that's all the tooling you'll
need to start learning how to program Windows as a /real/ programmer (not an MS
slave). (I assume a moderate knowledge of C itself). When you get to the
point where you can use the Win32 API to open a window, show a few lines of
text or some simple graphics, and respond to a mouse-click or keyboard event by
doing something sensible, then you'll have got the basics. By "basics" I mean
that you'd have a fundamental understanding of how a Windows program works.
From there on in, understanding almost any example, or using any given API is
just a matter of working your way through the sludge of MS API's -- a
distinctly wearisome task, but intricate rather than intrinsically difficult.
That sludge is why people with sense avoid Windows programming whenever they
can...
Note that COM is (at least conceptually, and in my opinion) independent from
the Win32 stuff -- it would have to be learned separately if you needed it.
As for scripts and the like - I will have to look into it. I haven't much
thought about it - maybe just specs on the LNK file format. If I could
read it, I could mod it.
A word of warning: I have only ever found one "spec" (actually a
reverse-engineering) of the LNK format. It was out of date and incorrect (as
became immediately obvious comparing a binary dump of a real LNK file with the
"spec"). As far as I know, the /only/ MS-sanctioned way to create links is
programmatically via the WScript COM object, as in the following WSH script:
======== makelink.js ==========
function makeDesktopLink(name, to)
{
var shell = WScript.CreateObject("WScript.Shell");
var desktop = shell.SpecialFolders("Desktop");
var link = shell.CreateShortcut(desktop + "\\" + name + ".lnk");
link.TargetPath = to;
link.Save();
}
makeDesktopLink("ScitTE", "C:\\Win32App\\Scite\\wscite168\\wscite\\SciTE.exe");
============================
For a reasonable-looking intro to scripting in this way:
http://www.code-magazine.com/article.aspx?quickid=0001061&page=1
-- chris
