MFC Regular DLLs and Handle Maps - C / C++ / MFC Discussion Boards

This is really worst than I expected, I've been looking at this for the past hour and this is what I found :

In my understanding of MFC and Win32 things, the different menus, don't show the "_" ( mnemonics ) when used with the mouse, but when the user press the "alt" key ( of "F10" ) the menus get into a keyboard navigation mode, and Windows will show the "_".

Me, just frustrated !

Max.

This is a new "feature" of Win2k & up. You can disable it under Display Properties->Effects.

_{And if words were wisdom, I'd be talking even more.}

The Offspring, I Choose

Shog9 wrote:
You can disable it under Display Properties->Effects

Ok, I get it ... Thanks....

M.

Hi All,

I'm working on some socket classes, and I would like to able to spy on the activity of a windows socket in IE. Specifically, I'd like to be able to intercept the buffer passed to the recv function.

Is there some sort of utility around for this? I found a sharewaer program, but it was too crippled to be useful.

Thanks,

Aaron

Matt Pietrek did something similiar in Sept'97 issue of MSJ. It may be in MSDN on your harddisk.

Tomasz Sowinski -- http://www.shooltz.com

Use a packet sniffer.

Sorry to dissapoint you all with my lack of a witty or poignant signature.

Hi Al

Hi all,

I've got a very difficult problem that I've spent several weeks trying to figure out. I think I finnaly know the issues, but not how to solve them. I humbley submit my predicament to you fine folks here on code project to see if anyone has any insight...

Let me describe the setup:
-I have a MFC regular DLL statically linked to MFC (I don't know what language or environment my DLL will be used from and I want to support the broadest range).
-This DLL globaly subclasses certain types of GUI objects. For the purpose of providing an example, I'll use the windows BUTTON api class for illustration here.
-The DLL calls ::SetClassLong and does some mumbo-jumbo to override all BUTTON WndProcs and set them to be ownerdrawn. At the same time, I subclass all of them to a special CoolButton class derived from the MFC CButton.
-I also subclass all Dialogs so that I can intercept WM_DRAWITEM messages and send them to the child based on my handle map rather than the app's (because the app doesn't know about my subclassed CoolButtons, it would send the DrawItem message to CButtons which would assert because the DrawItem function hasn't been overridden).

Everyone still with me Smile | :)

Everything works perfectly from other languages and from within MFC except in one case, and this is the root of the problem: When a button on a dialog has had a member variable of type CButton declared from within the calling application, I ASSERT on a call to CButton::DrawItem (because no override is present) at random times (for example right after a WM_KILLFOCUS message).

I think this happens because the message pump looks like this:
-Send WM_KILLFOCUS to the AfxWndProc
-AfxWndProc sends it down the pipe
-I intercept (remember I'm looking for WM_DRAWITEM messages for the parent so I've inserted myself here)
-I want to do the default action, so I pass the WM_FILLFOCUS to the old WndProc (which I got from my call to ::SetClassLong)
-The old WndProc does the default OnKillFocus action - everything works great up to here.
-If no member CButton variable has been declared, the old WndProc sends a WM_DRAWITEM to the parent, I intercept it, take action, and viola, everything works great! If a member CButton has been declared, the default WndProc bypasses the top level windows message routing routine, I never see the WM_DRAWITEM message, and by looking up the CButton member from the application's permanent handle map it calls the CButton::DrawItem and I crash Frown | :(

The solution, as I see it, is to replace the CButton member variable with my CoolButton inside the application's permanent message map. In fact, this approach works perfectly if I compile the dll code straight into the application rather than as a DLL. My problem is that I can't get to it from the DLL. So, and thank you for sticking with me through all this, here is the question:

Is it possible to get a functioning pointer to the application's CHandleMap structure (or otherwise manipulate the handle map) from within my regular DLL?

Thanks a bunch!

Dave

Dave Glick wrote:
The DLL calls ::SetClassLong and does some mumbo-jumbo to override all BUTTON WndProcs and set them to be ownerdrawn. At the same time, I subclass all of them to a special CoolButton class derived from the MFC CButton

Could you describe this step in more detailed fashion?

Dave Glick wrote:
I think this happens because the message pump looks like this:
-Send WM_KILLFOCUS to the AfxWndProc

WM_KILLFOCUS is sent (not posted through message loop/pump).

Tomasz Sowinski -- http://www.shooltz.com

Could you describe this step in more detailed fashion?

Sure - First I have a LRESULT CALLBACK MyWndProc() function that I've set up to process messages, I'll describe it more specificaly in a moment.

I create a CButton and then call ::SetClassLong using GCL_WNDPROC as the argument and then I store the return value for use in MyWndProc.

Inside MyWndProc, I watch for WM_PAINT messages (because this is the first message that gets sent after MFC has actually added it's member variables to the permanent message map - and because after I subclass, WM_PAINT won't get sent anymore for my ownerdrawn buttons) and when I find one, I create a new CoolButton and tell it to subclass the Wnd. It's in this step that I would unattach the member CButton from the application's permanent message map if I had access to it (In fact, the unattach is essential if this code is to be run from the application itself since a handle map can not have two MFC classes pointing to the same window handle).

Was this what you were looking for?

WM_KILLFOCUS is sent (not posted through message loop/pump).

My bad - in any case, it ends up going through my WndProc and then being sent on to the default one, which is what causes the crash when a member variable exists.

Thanks,

Dave

I think the problem is too complicated to get it resolved via posting on the board. If it doesn't broke trade secrets, feel free to send me the sources Smile | :)

Tomasz Sowinski -- http://www.shooltz.com

For a while my icon was rightm but it's now wrong. The program uses the right icon when it's running, but Explorer uses the "wrong" one.

How can I get my program's icon in explorer to be the one I want? (Changing the icon in a ashorcut doesn't count!)

Thanks

does someone has a pdf or e-book about win32 programming? I need one!

paladino_rapaz@bol.com.br

http://orion.ramapo.edu/~vmiller/Win32/
http://www.winprog.org/faq/

Hello,
How to use WM_COPY if I want to copy some text in other application?

::SendMessage(m_hWnd, WM_COPY, 0, 0);

I implemented this but it doesn't work. There's nothing in the clipboard.

Help me, please.
Blush | :O

Hey,

I think the problem might be in your m_hWnd variable. The WM_COPY message should get sent to the window from which you want the data - in this case, the Edit box from the other application. It can be a little tricky to get your hands on this hWnd. My suggestion would be to use ::FindWindow to locate the window in question (you'll need the class name, which is probably "EDIT", and also the window name, which you can get by using Spy++).

Hope that helps!

Dave

Are you sure your m_hWnd represents edit or combobox control? Only these window classes respond to WM_COPY message.

Tomasz Sowinski -- http://www.shooltz.com

I cant' figure how to show hidden toolbars....
Suppose I've a floating toolbar and I close it... if it's the main toolbar, there is a default command (ID_VIEW_TOOLBAR), but if I've many toolbars I can't change (nor get) the status of the others.... I tryed using "mytoolbar.ShowWindow(SW_SHOW)", but I can't get nay result.... someone has an idea?

Take a look at the ShowControlBar global function, that should do it.

Example use:
::ShowControlBar(&mytoolbar, /* true = show, false = hide */ true, /* true = delay showing/hiding it, false = show/hide is now */ false);

This function call will show the toolbar mytoolbar without delay.
Check MSDN for more details, though this is a pretty simple function with only three parameters. Tell me if it works!

Hope that helps!

Sincerely,
Alexander Wiseman

Est melior esse quam videri
It is better to be than to seem

Thanks, Yes, it works!

But now I can't find a command to GET the control status...

You mean to get whether the control is hidden or visible?

Try: mytoolbar.IsWindowVisible(), that should work.
Otherwise, you might try to keep a variable to track the status of the control bar.

Hope that helps!

Sincerely,
Alexander Wiseman

Est melior esse quam videri
It is better to be than to seem

Yes, that's!

I feel idiot... it was so obvious..... and I spent about 3-4 hours looking for such function in MSDN Smile | :)

Thanks!

Spending 3-4 hours trying to find a function, sounds like me on a good day Poke tongue | ;-P

Glad I could help!

Sincerely,
Alexander Wiseman

Est melior esse quam videri
It is better to be than to seem

I’ve used ADO for about 5 years now but only in single threaded applications. I’m going to begin work on an application that needs to have some worker threads connecting to a MS SQL Server. We figure that under worst-case scenario there could be 200 threads all executing queries against the db. Under an average load it will probably be more like 50 threads with db connections.

This application needs to be a stand-alone EXE (with a few dlls etc) therefore I can’t use MTS or some other middle-tier that would maintain a connection pool.

I really don’t want to create a new connection to the db each time I fire off a worker thread. Its not possible to share the same connection across the threads (right?) because I sure don’t want to serialize access to the single connection.

Has anyone else had to do something similar? Any design suggestions and ideas on how to implement this would be greatly appreciated.

Thanks in advance!

You can use a thread pool, each thread having its own DB connection that is active during the entire liftime of the thread itself. So, after a thread has executed a query, instead of terminating it can go to a "pending" state, ready to serve additional queries. This way you don't have the penaly of creating a thread and creating a DB connection each time a query has to be executed. Of course this needs some working out (is it the pool fixed, or do it vary in time according to the frequency of queries, etc.) but I think the approach can be appropriate.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo