Of Mice and Messages

[NoCforMe]

Nope. WM_LBUTTONDOWN has a bunch of flags in wParam,  and of course the mouse X and Y in lParam. Same for WM_LBUTTONUP and WM_MOUSEMOVE.

By the way, enjoyed that thread on C++ very much. I don't hate it (never really learned it myself, just C), but I can see why people do.

[NoCforMe]

It works!

Figured out how to have multiple windows share a common window proc.

Was wondering up above, hmm, how could I tell which window I'm handling this time around? lParam? No. wParam? No.

Well, duh! Just look at the window handle, dummy! (Talking to myself here.) After all, it's guaranteed to be unique.

It works. On creating a child window, store its handle in a global variable. Inside the childProc(), compare the handle passed to the routine to the stored one. If it matches, bingo! that's the child.

So I can just build me an array of structures, storing the handles there, plus all the interesting stuff I need for each child (text to paint, colors, sizes, etc., etc.). Search the list, matching the Windows handle to the stored ones, use the index to access the other stuff.

I think that's pretty slick ... of course, I'm sure some of you figured this out long ago.

[dedndave]

the trick is to design the code so that each window is treated the same
that way, you don't care which one it is   :bg
of course, that can't always be a good solution

[NoCforMe]

the trick is to design the code so that each window is treated the same
that way, you don't care which one it is   :bg
of course, that can't always be a good solution

Yes, I've learned that. My childProc() doesn't discriminate at all against any of its children. I guess you could say it's "orthogonal".

It works fine now; I'm wondering how well it'll work with lots and lots of children. Theoretically, it should be fine. Have to try it.

Hey, I'm still having some basic problems with my child windows, like cursor position whle dragging, repainting, etc. Would you be willing to take a look at my program if I posted it here (in a .zip)? or should I post code snippets?

Also, if you're  interested, I could post the essentials of my multiple-children-on-one-proc method, including a really easy way to generate lots and lots of windows using only one subroutine and some data structures.

[dedndave]

attach the complete program
i'll have a look

[NoCforMe]

OK, done.

Couple warnings: I use different INCLUDE paths (didn't like the default position of MASM32 in my folder structure).

A good deal of commented-out code.

If anything doesn't make sense to you, ask me. Hopefully you'll find it pretty straightforward.

Things I'm not happy with:

• Drag the child boxes around and look what happens to their borders when you drag them over the text at the bottom.  (However, dragging the box beyond the client edge restores them.)
  
• See how the cursor always jumps to the upper-left corner of the window.
  
• The background color of the drawn text is different from the window background. (Guess I need to set some more "brushes".)
  

[dedndave]

at first glance, things look pretty good, for the most part

there are a couple things i notice right away, however

1) i see that you do not have the masm32 folder in the drive root
this is likely to cause you problems in the future - it can be on any drive, but should be in the root
also, it is helpful to put the "[drive]:\masm32\bin" folder in the PATH system environment variable
let me know if you need guidance, there

2) i notice the mouse position at the bottom of the window
it is pretty easy to create a status bar and use SendMessage to set the text
i will find or make a simple example after i get out of the shower   :P
then, time permitting, i will look at the program again in more detail

[NoCforMe]

1) i see that you do not have the masm32 folder in the drive root
this is likely to cause you problems in the future - it can be on any drive, but should be in the root
also, it is helpful to put the "[drive]:\masm32\bin" folder in the PATH system environment variable
let me know if you need guidance, there

Thanks, but I think I've got that covered. I'm using 4DOS, my old-time favorite Windows shell (so much better than the default "command window"!).

Why on earth would I want to put that stuff in my root? I can easily set paths with 4DOS (or modify them on the fly if needed). My path to MASM is f:\techstuff\masm32\bin. 4DOS has no problems finding my executables. Seems like different strokes for different folks, no? (Unless there's some potential problem with programs finding DLLs?)

Of course, there are problems with other people's code, but I can always edit (or, my preference, lift out the "good parts" and copy them into my code).

Anyway, thanks for your help.

[dedndave]

lol
well - have a look at masm32\include\masm32rt.inc
you will see what issues may arise
at any rate - it is a simple thing
you can just move the folder and change the path setting
no need to completely re-install masm32

[NoCforMe]

lol
well - have a look at masm32\include\masm32rt.inc
you will see what issues may arise

I see what you mean. The solution is simple: don't use masm32rt.inc. I think I can figure out which include files I need in my projects. (Or I could edit the include files to tailor them to my liking.)

[dedndave]

just make a copy of it, name it "MyMasm32rt.inc", and edit the paths   :U

that way, when you want to assemble an example, you just add 2 letters "My"   :P

[jj2007]

just make a copy of it, name it "MyMasm32rt.inc", and edit the paths   :U

that way, when you want to assemble an example, you just add 2 letters "My"   :P

ça peut crèer pas mal de problèmes si tout le monde parle une autre langue... il y'à de bonnes raisons pq on a une certaine standardisation: ça marche!

[dedndave]

all may be well if he runs under 4dos, and "techstuff" becomes the root
not sure how that program works

[NoCforMe]

Well, yes, all is fine and dandy under 4DOS (a product of JP Software if you're interested; it's now morphed into something called "Take Command"). It's just a command shell, just like the default Windows "Command prompt". But so much nicer; has memory-based batch files (.BTMs), customizeable everything, editable PATHs, lots of other goodies. I've used it since the 1990s.

And no, I didn't make \techstuff the root; why would I want to do that? I simply set my path to point to the MASM "bin" folder (Path=F:\TECHSTUFF\MASM32\BIN). Easy peasy. All the "makeit.bat" files in the MASM32 examples work fine.

I hope I haven't opened a can of worms here; after reading jj's Masm32 page, I can see why he suggests people use the standard locations for things (so that other people can test their code). So I pledge that if I post code here that might actually be used by others, I'll take care that the path names for include files, etc., are the standard ones. For my own projects, however, I really like to be able to put things where I want them.

[dedndave]

it's ok - you're bound to bump into problems at some point
when you do, it's an easy fix   :P

here is a status bar that displays mouse position
the stuff i added to make the status bar is surrounded by "$$$$$$"