Of Mice and Messages

[jj2007]

You can use conditional assembly to make testing easier:

dm10:   INVOKE   MoveWindow, ChildHandle, pt.x, pt.y, $childWidth, $childHeight, TRUE
   UseInvRect = 1
   if UseInvRect
      INVOKE   InvalidateRect, ChildHandle, NULL, TRUE
   else
      INVOKE RedrawWindow, ChildHandle,  NULL, NULL, RDW_FRAME OR RDW_INVALIDATE
   endif

Case 1 redraws the background after moving the child over the status bar, case 0 doesn't.

[NoCforMe]

Thanks; that makes sense, and jibes with what actually happens.

Can someone tell me exactly what kind of windows I've created here? They don't seem to fit the categories of windows that I see described in the references (MSDN). The strangest part of their behavior is how the mouse cursor always attaches itself to the upper-left corner. (Although this may be a side effect of doing something wrong in my window-moving code.) It behaves like there's a one-pixel "handle" at (0,0).

Here's what I actually want: small windows that I can drag by clicking anywhere in the interior of the window, and resizeable. (Resizing is easy: just add the WS_SIZEBOX style. Of course, for some WEIRD reason, this also forces the box to acquire the WS_THICKFRAME style.)

Let me tell you what I'm after here: I thought, perhaps a little grandiosely, that I might create a tool to create resource templates. Like the resource editors in Visual {xxx}, but much simplified. So the child windows could represent fixed-text items, for instance. I want to be able to position them, resize them (by grabbing their frames), and to put stuff in them (like text, maybe even bitmaps). So what kind of child windows do I want? I'm starting to suspect that this will require owner-draw controls to do it properly. Haven't learned that yet ...

[jj2007]

Can someone tell me exactly what kind of windows I've created here? They don't seem to fit the categories of windows that I see described in the references (MSDN). The strangest part of their behavior is how the mouse cursor always attaches itself to the upper-left corner. (Although this may be a side effect of doing something wrong in my window-moving code.) It behaves like there's a one-pixel "handle" at (0,0).

You need the initial position of the mouse, and then use an offset for MoveWindow.

for some WEIRD reason, this also forces the box to acquire the WS_THICKFRAME style.)

You can get rid of the thick frame by subclassing and capturing the nc paint message.

BTW, check RDW_FRAME OR RDW_INVALIDATE or RDW_ERASE

[dedndave]

the windows are Static Controls
they are a special window because the OS has predefined the class for them
the OS also provides the WndProc for these special control classes
typically, they are used in dialog boxes

you can create them by using CreateWindowEx, just as any other window
but, you do not have to register the class, just use the string 'Static' as the class name

http://msdn.microsoft.com/en-us/library/windows/desktop/bb773173%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773169%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb760769%28v=VS.85%29.aspx

likewise, you can register your own class and make them any way you like
you then have to provide the WndProc code

once i get my static controls in there, i will be able to constrain the box inside the client
this will be done by using the mouse position when WM_LBUTTONDOWN is received
and by subtracting the complimentary window dimensions from the clip rectange

[dedndave]

reading through some of the previous posts, here...

I guess at this point I had planned on playing this game (learning assembly language forWindows)
my way, by my rules, on my computer. I hadn't envisioned joining a "community"  just yet.

:bg
i look at it this way...
i am in the "learn mode"
once i have learned everything there is to know about windows, i can do it however i like
unfortunately, i probably won't live that long   :P

I want to be able to position them, resize them (by grabbing their frames), and to put stuff in them
(like text, maybe even bitmaps). So what kind of child windows do I want? I'm starting to suspect
that this will require owner-draw controls to do it properly.

well - we don't want static controls, then
they are meant to be, well, static   :bg
you could almost use an MDI arrangement - a bit clumsy for some of the controls you will want to add
i think if i were doing what you want to do,
i would use a sizable window for each type of control that the user may want to add
that means they will have borders while many of the controls do not
anyways, you put the type of control they ask for inside the sizing window and size the control when they size the window
you could create a class for each control type, each with a special WndProc
they ask for a slider, your "slider-class" WndProc handles all the stuff that is appropriate for a slider
they ask for a button, your "button-class" WndProc handles all the stuff that is appropriate for a button

[NoCforMe]

Just to make things clear (because this thread is starting to get confused, and I'm not sure you really understand what I'm after here, or what my knowledge of assembly language is): are you suggesting that I create these controls as small child windows, like what I have now, but with other controls (text, bitmaps, etc.) inside them? I did want one type to be a static-text control creator (not  a static control in and of itself--get it?) that would allow the user to type text into it.

Currently, the child windows are not static-text windows. (I removed all the static-text stuff when I pulled that font-selection combo box out.)

Again, I need a type of window that:

• Allows the user to grab it and move it at any point, inside or on the edge;
  
• Is resizeable (I know how to do that)
  
• Can accept text or bitmap images
  
• Is properly repainted when it goes behind other objects or under the status bar.
  

For now I think I can live with the child window being able to be dragged beneath the status bar; not a huge deal.

I'd really like to get this right from the get-go, both for the sake of my learning, and to get the bugs worked out before I get a big, complicated application going and have to debug it. So it's important that I understand what's going on conceptually, as well as how it's implemented.

I'm almost convinced that this needs to be an owner-draw type of window. Any suggestions in this area appreciated.

I looked through Iczelion's tutorials, but there doesn't seem to be much on this subject specifically. (Bits and pieces here and there.)

[dedndave]

yes - i think what you are after is a button that looks like a button
if they ask for an edit box, it looks like an edit box
then, they can size and place them as desired

i have something in works - it only supports buttons and trackbars (sliders)
but, that should be enough to build on by adding the other control types

when they add a slider, it opens a sliderWin
they can size that window however they like
when they do, the slider that is inside it will size with the window (always filling the window)
same for buttons, except it opens a buttonWin

now, let's take buttons as an example
besides the size and location, there are other attributes like text, color, control ID number
you can handle it however you like - i was thinking if they right-click on it, a dialog comes up and lets them set those

[dedndave]

i was going to point you at Ketil Olsen's ResEd program, but i am having a hard time finding a link
you might get some ideas from his program

here you go
http://www.oby.ro/rad_asm/resed/index.html
Ketil is a very powerful windows programmer   :U

[NoCforMe]

I'm still not clear what you're suggesting. You're saying make the control a button: is that the containing window? Isn't a button a type of  control?

I thought what you were saying was to create a child window, then put a control (slider, edit control, whatever) inside it. Is that it?

(Regarding your link) Yes, that looks like what I'm after (although I'm thinking of a much more modest program!). It looks like you can download the app for free (which is nice), but not the source. But yes, that's the idea.

[dedndave]

I thought what you were saying was to create a child window, then
put a control (slider, edit control, whatever) inside it. Is that it?

yes - that's the idea
you could have a right-click context menu, too - they are easy to implement   :P
if they right-click on a button window, it gives them a list of things they can edit for that type of control
just a few thoughts

[Gunner]

The other cool and free Asm IDE is WinASM.  It is now open source, you could DL that and see how they do it. http://www.winasm.net/forum/index.php?showtopic=3713

[NoCforMe]

Dave, I should first say thank you--that was exactly what I was looking for!

OK, I don't have to write this app now; forget everything I said.

Just kidding. I still want to know how to do this. Yes, source is included, but wow: this is one hell of a complicated program.

The controls are EXACTLY what I was looking for. When you create a new control, you get box with the name of the control type (e.g., IDC_CHK) in it, plus a graphic of the control (checkbox, radio button, etc.). When you select the control, you see 9 resize handles, and you can grab it and put it anywhere you want to.

Anyone want to download this and tell me just where this happens in the code? (Hint: I think it's somewhere in the file DlgEdt.asm.)

Anyhow, I'll have fun playing with this and looking through the code.

[dedndave]

oops - wrong thread   :P

[Gunner]

Dave, did you send him the source?  Is he to be trusted to be in our "secret" society  :bdg

I would think it is in CreateCtl but that is as far as I will go.  AFAIK, ResEdit NOR RadASM is open source, so I won't discuss modifying the source here.

[NoCforMe]

Believe me, I have no desire to modify that source! Angels fear to tread and all that.

I'd like to learn how it works, and I might borrow stuff from it for my own code.

So what or where is CreateCtl? Can't find that in any of the .asm files.