|
Hi,
I'm running Visual C++ .Net 2003 with Service Pack 1, and .Net Framework 1.1, and I'm having issues with using GetComboBoxInfo and GetScrollBarInfo, even though they are available as functions when using the intellisense.
Although I've seen, tried and used a workaround to use the GetComboBoxInfo function, I was wondering if there is an update I need to install to avoid having to use the workarounds.
TIA
Tony
|
|
|
|
|
maycockt wrote: I'm having issues with using GetComboBoxInfo and GetScrollBarInfo
What issues did you come across?
|
|
|
|
|
OOps, I should have elaboarated on that.
Even though I have the option to use the functions, when trying to declare a COMBOBOXINFO or SCROLLBARINFO they come up as undeclared identifier, and GetScrollBarInfo is identifier not found.
As I said, I have used a workaround involving specifically declaring the struct and declaring links to USER32.dll etc.
What I really want to know is if there is an update that takes away the requirement to put so many workarounds in place to use this functionality?
TIA
Tony
|
|
|
|
|
maycockt wrote: ...and GetScrollBarInfo is identifier not found.
Look at the function prototype in winuser.h. Do you have WINVER defined to be 0x0500 or greater?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi Guys,
Thanks for your help.
Looking in the project settings I see the WINVER was initially configured for 0x410.
Nearly there 
Tony
|
|
|
|
|
Hi,
How can we identify the valid hardware MAC address from the list obtained by GetAdaptersInfo API?
For example, in my machine there is a real Network Adapter and a Microsoft Loopback Adapter. I need to get the MAC address of the real Network Adapter.
Thanks in advance! - ns ami -
|
|
|
|
|
| The documentation here[^] will explain it to you. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Did I miss something??? 
If you mentioned about MIB_IF_TYPE_ETHERNET, it is coming same for both real hardware and microsoft loopback.
Could you please clarify? - ns ami -
|
|
|
|
|
| What about MIB_IF_TYPE_LOOPBACK ? txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
| For both hardware adapter and Microsoft Loopback adapter, the type obtained is MIB_IF_TYPE_ETHERNET. Not MIB_IF_TYPE_LOOPBACK for Microsoft Loopback adapter. So I cannot distinguish which is the hardware adapter. - ns ami -
|
|
|
|
|
| OK, I guess you will have to try something else. Sorry, a long time since I used this in anger. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
| I think you need NetWkstaTransportEnum([^]), it will out the MAC address buffer. Величие не Бога может быть недооценена.
|
|
|
|
|
Something in my app. (C/Win32)is setting SetLastError and I want to debug it, eg capture all calls in my process to this function.
Any idea how I'd configure VS to break here?
Thanks
|
|
|
|
|
| Maybe try hooking SetLastError, check out API hooking revealed[^] for details. > The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
This is how I do this -
Start Windbg.exe.
Open your executable.
Set the break point - bp kernel32!SetLastError
When it breaks issue any of the stack backtrace commands - k, kp, kP etc.
|
|
|
|
|
Just call SetLastError(0); by starting of you process.
Set a breakpoint there and then - by stopping -
take the "Go to Disassembly" from the context menu...
Now - step by F10 to "call", then - F11 to "jmp", then - F11 to "mov".
Set your second breakpoint here to keep all calls of SetLastError(..)
and press F5 to get it
|
|
|
|
|
Thanks for the responses. I managed to find a breakpoint for some function that releases memory. Need to brush up on my assembly perhaps? 
Not quite what I asked, however a chap at work suggested typing $err into the watch window, this dispays the current value of GetLastError so I can step through code seeing where it changes.
|
|
|
|
|
I am confused by reading many articles.
Can any one tell me how many message queues are there in dialog based application.
Are there separate message queues for each window or each thread has its own message queue.
|
|
|
|
|
sharda.bhagwatkar wrote: Can any one tell me how many message queues are there in dialog based application.
Are there separate message queues for each window or each thread has its own message queue.
A dialog based application has one message queue.
A thread has its own message queue, if it's an UI thread. As a result, a window can have more than one message queue, if it has multiple UI threads running within.
sharda.bhagwatkar wrote: I am confused by reading many articles.
Read this: UI Threads explained by Dr. Joseph Newcomer[^]
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Hi Rajesh,
Hope you're good and having fun! 
I got a little confused when I read your post....
Rajesh R Subramanian wrote: As a result, a window can have more than one message queue, if it has multiple UI threads running within.
Ummm...
Not really sure what you mean here, but to my knowledge a window is only served by one message queue and pump in the sense that messages sent to the window will be queued in the message queue that belongs to the thread that created the window in the first place.
On the other hand, you may of course spawn new UI-threads from your "window" and create new windows in the newly created thread.
Or, do you really mean that messages sent to a window may end up in different threads/queues?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi Roger,
Yep, I'm good. Thanks. How's it going for you?
Roger Stoltz wrote: a window is only served by one message queue and pump in the sense that messages sent to the window will be queued in the message queue that belongs to the thread that created the window in the first place.
I said a Window (the program) can have more than one Message Queue running, simply by creating UI threads within. These message queues need not necessarily have anything to do with the message queue of the application window itself (to which all the messages are posted from the outside world). When I need a queued event dispatching mechanism, I can create UI threads.
Roger Stoltz wrote: On the other hand, you may of course spawn new UI-threads from your "window" and create new windows in the newly created thread.
I think that the term "UI thread" is horribly misleading, as a UI thread need not have a UI associated with it at all! I can have UI threads running around without associating any of those to a window.
Roger Stoltz wrote: Or, do you really mean that messages sent to a window may end up in different threads/queues?
I can of course re-route the messages internally if I have additional UI threads running within.
Example: A server program that I wrote, when it receives requests to compress rendered output videos, it just routes the message to a slave (an "ui" thread) and returns. The slave would automatically process the requests in a FIFO basis. The compression need not be done urgently, so I avoid additional threads, and at the same time, eventually every request will be processed sooner or later.
I'm not sure I got your queries right; let me know if I've been unclear somewhere.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Thanks for the replies and articles.
This is my understanding
1. device driver for the mouse or keyboard converts the input into messages and places them in the system message queue
2. The system removes the messages, one at a time, from the system message queue and then posts them to the message queue of the thread that created the destination window. e.g. in dialog based application it is a message queue associated with CWinThread (main thread) which has its message loop also.
3. Hence the message queue and message loop are associated with Thread not the window.
4. When UI thread is created inside the application, intially it does have message queue and message loop, but when some message is posted it creates the message queue and message loop on demand.
I still have one more query here. What will happen in case when modal dialog is launch on some button click of dialog based application and how will be the case with modeless dialog boxe.
|
|
|
|
|
Yeah, I'm good too.
Looks like I've just been assigned to something that looks very promising and may last for at least this year. So I'm happy.
Rajesh R Subramanian wrote: I'm not sure I got your queries right; let me know if I've been unclear somewhere.
Ohhh, now you're asking for it my friend...
Rajesh R Subramanian wrote: I said a Window (the program) can have more than one Message Queue running
I think this adds to the confusion. It looks like you're saying that a window is a program and of course it's not.
To my understanding the question was never about whether an application can have more than one thread that has a message queue, or if an application may have multiple message queues.
I interpret the OP's question in short terms as "does the message queue belong to a thread or a window" and the correct answer for that in equally short terms can only be "the thread".
Rajesh R Subramanian wrote: I think that the term "UI thread" is horribly misleading, as a UI thread need not have a UI associated with it at all!
Agreed at least a 100%!
The concept of "UI-thread" only makes sense as it is necessary to process messages when GUI objects are created in the thread.
Rajesh R Subramanian wrote: I can of course re-route the messages internally if I have additional UI threads running within.
Yep, that's possible. But that's more related to ::PostThreadMessage() than window objects.
Never mind, it's beside the point.
I think the essential part of my point is that a window will only receive messages in the message queue that belongs to the thread that created the window.
We can look at it this way:
You send messages to windows by calling either ::SendMessage() or ::PostMessage(). They both need a window handle as argument.
The window retrieves the messages sent to it by calling e.g. ::GetMessage(), which also needs a window handle. The point I'm trying to make can be found in the documentation for ::GetMessage() that says "the window must belong to the calling thread".
This means that a UI-thread can only have one message queue and since a window can only belong to one thread, it can only have one message queue where messages sent to the window will be put.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Rajesh R Subramanian wrote:
I said a Window (the program) can have more than one Message Queue running
I think this adds to the confusion. It looks like you're saying that a window is a program and of course it's not.
I took the simplest example - a dialog application, where there's just one message queue and that holds the messages posted to that very window by the outside world.
Roger Stoltz wrote: I interpret the OP's question in short terms as "does the message queue belong to a thread or a window" and the correct answer for that in equally short terms can only be "the thread".
Which I mentioned as well, only with added information that there could be additional message queues without windows associated to them.
I reckon we both have a way with our words, and we always get into discussions only to settle on the same boat after a while; saying: Oh yeah? You meant *that*. Right! Fun thing, if you ask me.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
sharda.bhagwatkar wrote: Are there separate message queues for each window or each thread has its own message queue.
A window does not have a message queue of its own. Multiple windows may be served by the message queue and message pump in the User Interface thread that the windows are created from.
In e.g. a simple dialog-based application there is initially only one thread and even if you create new windows, they will be served by the message queue in that thread. Keep in mind that all those small buttons and other controls are windows as well.
Every thread spawned is initially without a message queue. There are two kind of threads: worker threads and User Interface threads. Worker threads won't have a message queue, but UI-threads will get a message queue created when a message is sent, or posted, to the thread.
Read more about it in this small section[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
