|
So whether you want to use a MFC DLL in .net?
else case, it is wont be possible except the one mentioned in above answer.Величие не Бога может быть недооценена.
|
|
|
|
|
Hello Dear,
I am tacking about .net dll in MFC .If you can think then I Can.
|
|
|
|
|
Hello Dear,
I am taking about How to use .net dll in MFC ;If you can think then I Can.
|
|
|
|
|
|
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
|
|
|
|