C / C++ / MFC

Christian Graus14-Mar-02 20:41

14-Mar-02 20:41

It would not be fast at all if it was a list.

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

Shog⁹15-Mar-02 4:59

Shog⁹

15-Mar-02 4:59

why is this?

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

The Offspring, I Choose

Christian Graus15-Mar-02 9:12

15-Mar-02 9:12

Because you'd have indices into a container to look up the actual strings, and list lookups require walking the list, they are slow compared to arrays which have instant lookup.

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

Shog⁹15-Mar-02 9:23

Shog⁹

15-Mar-02 9:23

Yes that would be slow. For a list i think you'd want to go with pointers.

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

The Offspring, I Choose

Matt Weagle14-Mar-02 17:29

Matt Weagle

14-Mar-02 17:29

You could also look at the STL's pair<>.

Tomasz Sowinski15-Mar-02 0:14

can anyone help me with this?

15-Mar-02 0:14

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

lucy14-Mar-02 11:36

lucy

14-Mar-02 11:36

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);
   // draw a cirle
   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? Confused | :confused:

Thank you very much for your help!
Rose | [Rose]

Re: can anyone help me with this?

Christian Graus14-Mar-02 11:40

Re: can anyone help me with this?

14-Mar-02 11:40

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

lucy15-Mar-02 2:47

lucy

15-Mar-02 2:47

Yeah, got it. The pt is too low to be displayed.
Thank you a lot, Christian! Rose | [Rose]

undeclared identifier

Shotgun14-Mar-02 10:52

Shotgun

14-Mar-02 10:52

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

Re: undeclared identifier

Christian Graus14-Mar-02 11:41

Should Contextual menu show mnemonics ?

14-Mar-02 11:41

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

Maximilien14-Mar-02 9:30

Maximilien

14-Mar-02 9:30

[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() );
 // own method that really returns the string with the "&"
 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

Re: Contextual menu with/without mnemonics ?

Tomasz Sowinski14-Mar-02 9:59

Re: Should Contextual menu show mnemonics ?

14-Mar-02 9:59

It this a question or answer?

Jig | [Dance]

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

Maximilien14-Mar-02 10:49

Maximilien

14-Mar-02 10:49

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.

Re: Should Contextual menu show mnemonics ?

Shog⁹14-Mar-02 11:09

Shog⁹

14-Mar-02 11:09

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

Re: Should Contextual menu show mnemonics ?

Maximilien14-Mar-02 13:15

Maximilien

14-Mar-02 13:15

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

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

M.

l,Winsock Spy?

Aaron Schaefer14-Mar-02 8:56

Aaron Schaefer

14-Mar-02 8:56

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

Re: l,Winsock Spy?

Tomasz Sowinski14-Mar-02 9:17

MFC Regular DLLs and Handle Maps

14-Mar-02 9:17

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

Re: l,Winsock Spy?

Jon Hulatt15-Mar-02 0:48

Jon Hulatt

15-Mar-02 0:48

Use a packet sniffer.

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

l,Winsock Spy?

Aaron Schaefer14-Mar-02 8:55

Aaron Schaefer

14-Mar-02 8:55

Hi Al

Dave Glick14-Mar-02 8:20

Dave Glick

14-Mar-02 8:20

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

Re: MFC Regular DLLs and Handle Maps

Tomasz Sowinski14-Mar-02 8:42

Re: MFC Regular DLLs and Handle Maps

14-Mar-02 8:42

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

Dave Glick14-Mar-02 8:55

Dave Glick

14-Mar-02 8:55

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

Re: MFC Regular DLLs and Handle Maps

Tomasz Sowinski14-Mar-02 9:27