|
You could also look at the STL's pair<>.
|
|
|
|
|
You'll need a containter for strings and two maps - one for each 'way'. STL classes will be OK for that.
Aggregate these objects into one class, provide an interface - that's all.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I am using Chris' DIBSection wrapper for Win32 and WinCE. It is a great class, it's easy to use and very powerful.
But when I am using it, I have a question:
At first, I opened a 256-grey-scale bitmap file, using
m_pdib->Load("mybitmap.bmp");
Then in OnDraw(CDC *pDC)
{
m_pdib->Draw(pDC, pt, TRUE);
CPen redPen;
VERIFY(redPen.CreatePen(PS_SOLID, 1, RGB(255,0,0)));
CPen *pOldPen = pDC->SelectObject(&redPen);
pDC->Ellipse(pt.x, pt.y, pt.x+10, pt.y+10);
pDC->SelectObject(pOldPen);
}
The problem is: the bitmap file will be displayed correctly, but the red circle will not be displayed. I tried to use a white pen, but the circle couldn't be drawn either.
What did I do wrong? 
Thank you very much for your help!
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Are you sure values in pt are good ? Have you tried a hard coded constant to check ? Maybe pt is in screen co-ordinates, and needs ScreenToClient called on it ?
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Yeah, got it. The pt is too low to be displayed.
Thank you a lot, Christian!
|
|
|
|
|
just a newbie in c++ here
when i create a new mfc project, i add my buttons
and create a variable name for them then mapp anything
i need to, all fine, when i add a listbox or listview i get a
"undeclared identifier" for the List name, what am i doing wrong?
shotgun
|
|
|
|
|
For some reason, the variable is not in your header file.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
[Updated...]
On VC++ 6.something, and building on Win2000...
Should contextual menus have mnemonics ( display them ? ) ?
This is what I do, and doesn't seems to show mnemonics on contextual menus... :
...
CMenu menuTemp;
VERIFY(menuTemp.LoadMenu(IDM_MY_MENU) );
CMenu* pPopup = menuTemp.GetSubMenu(0);
ASSERT(pPopup != NULL);
VERIFY( pPopup->TrackPopupMenu(TPM_RIGHTBUTTON,pt.x,pt.y, AfxGetMainWnd()) );
...
and goes to to the ON_UPDATE_COMMAND_UI handler ...
void CMyClass::OnUpdateMenuItem(CCmdUI* pCmdUI )
{
pCmdUI->Enable( SomeCheck() );
CString s = AddAccelerator(pCmdUI, 0)
pCmdUI->SetText( s );
}
the resources have all the "&" at the right places ... and the handler is also used for the main app. menu ( and the mnemonics are displayed ! ).
Thanks.
Max
|
|
|
|
|
|
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 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 
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 
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
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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
