Font and Color

[Gunner]

No, if you return 0 in eax for WM_CTLCOLORSTATIC that is the same a NULL_BRUSH
You have to return a valid handle to a brush so the OS can paint the background...
What he has is the correct way

I have to admit, I'm lost as to the purpose of GetStockObject, let alone why in that example you gave me it's at the end before returning. I do however know that if it's omitted, nothing changes.

What is not to understand?  You are not painting the background yourself (although you can) so you have to tell the OS what brush to paint the background with...  GetStockObject gets a handle to a brush you choose, and the OS uses that to paint the background...  :dazzled:

[Shooter]

i am a n00b, but i am learning

http://www.urbandictionary.com/define.php?term=n00bs
That does not sound like you Dave  :P

Hahaha, I like number 3 on that list.  :bg


Rob, I guessed you missed my edit a few moments ago.

[Shooter]

OK, one more question about all of this: So far, my text's color is being changed based on the

Code Select Expand

DlgProc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
mov eax,uMsg
.if eax==WM_INITDIALOG
.elseif eax==WM_CTLCOLORSTATIC
(code)
.endif
mov eax,TRUE
ret
DlgProc endp

What if I wanted to change the color of the text based upon a button click or some other event?



By the way, I did make one small change based upon what you said about stability:

Code Select Expand

.elseif eax==WM_CTLCOLORSTATIC
invoke GetDlgItem,hWin,IDC_STC6
.if eax==lParam
invoke SetBkMode,wParam,TRANSPARENT
invoke SetTextColor,wParam,Red
;invoke GetStockObject,NULL_PEN
invoke GetSysColorBrush, COLOR_BTNFACE
ret
.endif
-Shooter

[donkey]

COLOR_WINDOW+1

there is a list of EQUates starting with "COLOR_" in windows.inc
you can use it directly but, for some reason that i haven't figured out, you always have to add 1

Because 0 (COLOR_SCROLLBAR) is reserved for no brush by CreateWindowEx (WNDCLASSEX.hbrBackground), which you use if want to paint your own background. By adding 1 you can still use all of the system color indexes, simple as that.

[donkey]

IDs, Handles and device contexts.

It is incredibly important to understand the role of objects in Windows, they are at the heart of the OS. For this discussion I will call the OS Win32 as opposed to Windows since it tends to confuse things when both the object and OS have the same names.

Reading this thread has me thinking that Shooter is having an issue grasping a few basic concepts in Win32. One of the primary ones is the difference between an ID and a handle which is related to the concept of objects in general. When you create a window in your editor of choice (be it RadASM, WinAsm, EasyCode or any other) you assign it an ID. A window is simply an object that you can manipulate using messages and functions, it can be a button, static, listbox or another control or it can be a container, like a dialog or window. The WNDCLASSEX structure describes certain properties of the window to Win32, for example how it is redrawn, what colors to use and the address of its message processing procedure. The ID that you assign to the window at creation is not necessarily unique, for example two dialogs can both have a button with the identifier IDOK (1) so how can Win32 distinguish them in order to make sure you are manipulating the right button ? It assigns a unique handle to every object that your program creates, references or uses. Windows, dialogs and controls fall into the winuser (User32) family (called a namespace) of objects and are the primary graphical interface of the OS. Another family (or namespace) of objects are responsible for the actual drawing of the windows and controls, those are the GDI objects, they provide a consistent interface between your program and the device you are drawing on, normally the screen but it could also be a printer etc... GDI objects include Pens and Brushes among other things and like all objects they are assigned a unique handle to identify them to Win32. When you use a pen or a brush you must specify a drawing mode or use the default, you do this with functions such as SetBkMode and other GDI level functions. Drawing something is a very complex process and the GDI is designed to make it easy by using Device Contexts, the device context can be seen as a Rosetta Stone that is used to translate the GDI commands to something the video card or printers driver is capable of and can execute. If the user mode driver through the Device Context informs the GDI that it is not capable of completing a specific command the GDI will break it down into steps that it can complete called ROPs. You can see an example of raw ROPs when you bitblt a graphic to the screen. The major advantage of all of this "under the hood" complexity is that for the most part all drawing is device independent, that is that whatever your final output device, the same GDI functions will yield the approximately same results. For that reason Win32 requires that you pass every drawing command through a device context which in turn is used to "translate" for the device driver. Device Contexts can also be seen as objects and therefore are assigned a unique handle to identify them. Other types of objects are synchronization objects, files, folders, devices, processes, memory, threads and pretty much everything else in Win32 that is handled through the Executive. Every object created by the executive consumes resources in your computer and you can quickly run out of available resource handles and memory if you misuse them, for this reason any objects you create must be released with the appropriate destructor function, for example DeleteObject for brushes or DestroyWindow for windows. In some cases Win32 creates the object and handles its destruction as is the case in the handles returned from GetStockObject, for those objects it is important not to call a destructor function, they were not created by you and therefor should not be destroyed by you. When it comes to windows and controls, you can generally get away with not destroying them, Win32 will do that when you close the window or terminate the process. Most entries at MSDN for creating objects specify its destructor API somewhere in the notes so read the entire entry and it will save you many a headache in the future.

Edgar

[dedndave]

very nice, Edgar
thanks for taking the time   :U
very clear and concise

[Shooter]

Edgar,
WOW! Very informative (took me four times to read through it all though, even after breaking it down into paragraphs).

I've gotten the gist about Handles and IDs, but there is still so much I'm not sure of. For example, I know that when an event occurs, a message is sent so that it can be handled appropriately (via 'traps' like WM_COMMAND). My confusion about that is knowing what 'traps' are available for each device, control, container, etc.

As was in this current thread's case, I had no knowledge about WM_CTLCOLORSTATIC, or even where to look for it. MSDN's site lists a few (39,500,000) informative pages about "Static Text", but I'm a slow reader and get frustrated after the first million or so pages.  :wink

The point I'm trying to convey is that while there are some very well documented help files and sites (and some poorly ones as well), there doesn't seem to be a very well organized manner in which to search said locations. If you know of a link or help file on MSDN that is found only via the phrase "Static Text" and contains WM_CTLCOLORSTATIC, I'd love to see it... possibly I'll learn the structure of the type of help files I'm needing for future reference.  :bg

A static control, or an edit control that is read-only or disabled, sends the WM_CTLCOLORSTATIC message to its parent window when the control is about to be drawn

So my other question still remains:

What if I wanted to change the color of the text based upon a button click or some other event?

If I included a button to change IDC_STC3's color, I'd add an event handler for that button and pretty much do as I've done before?

Something that confuses me about this code, and it's blocking me from creating a PROC using it...

invoke GetDlgItem,hWin,IDC_STC3
.if eax==lParam
     invoke SetBkMode,wParam,TRANSPARENT
     invoke SetTextColor,wParam,Purple
     invoke GetSysColorBrush, COLOR_BTNFACE
     ret
.endif

What is lParam holding that is needed to match eax, and how do I pass this to the PROC I'm trying to build?
-Shooter

[donkey]

Hi Shooter,

To begin with if you want to know anything about controls you go to the source, MSDN:

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

for example the static control can be found under Windows Controls\Control Library\Static Control. as you can see it discusses how to use the control, lists all messages and functions related to it and even provides sample code in C. Its just a matter of looking in the right place, something that you will eventually become adept at.

For the lParam being checked against EAX, RTFM. You first have to understand that GetDlgItem returns the window handle associated with the ID number of a control. So at the time of the .IF comparison EAX contains the handle associated with IDC_STC3 in other words the handle to the static you want to manipulate. Since the WM_CTLCOLORSTATIC message documentation at MSDN states:

lParam

    Handle to the static control.

That says that when the message is sent the handle to the static is present in the lParam position on the stack. Why would Windows bother to do this ? Well, you might have 2 or even hundreds of statics on a given dialog and must be able to respond to the correct one. In order to ensure that you can do this Windows identifies the static with its unique handle and by comparing it with EAX which contains the value of the handle you are interested in you can determine whether the static that is about to be redrawn is the one you want to color, if not then you skip it.

To change the color based on a button click you would toggle an application defined flag when a button is pressed then call InvalidateRect to invalidate the static, forcing Windows to redraw it. At that point a WM_CTLCOLORSTATIC is sent and you can set the text color based on the value of your toggle flag.

Edgar

[jj2007]

if you want to know anything about controls you go to...

"go to Edgar" would be a good option, too - you should teach Windows :U

If Edgar is absent, googling for MSDN WhatEverFunction is also a good choice.

[Shooter]

if you want to know anything about controls you go to...

"go to Edgar" would be a good option, too - you should teach Windows :U

If Edgar is absent, googling for MSDN WhatEverFunction is also a good choice.

Haha, I'm learning more and more from Edgar than I thought possible.

[dedndave]

we now consider you to be Edgar's pupil - hands off   :P

[oex]

aye aye there's a joke in there somewhere :lol

[Shooter]

we now consider you to be Edgar's pupil - hands off   :P

Hahahahahaha, wait, WHAT?  :eek