C / C++ / MFC

17-Apr-02 12:22

OK, then this is another bug. You should probably report it to the NG I mentioned in my post.

Virtual desktops?

generic_user_id17-Apr-02 9:35

generic_user_id

17-Apr-02 9:35

I would like to learn something about virtual desktops, but it's hard to find some articles or msdn info on it.

Is there some sort of function in Windows that makes it possible to switch desktops? As far as I know windows does support it completely, so it shouldn't be hard to code.

Got any links or information?

Cheers!

Mike Nordell17-Apr-02 9:54

17-Apr-02 9:54

It's not fully supported (f.ex. creating a new desktop still gets SystemParametersInfo to return the working area of a desktop with an Explorer bar), and you can't move windows from one desktop to another like you'd expect from any other OS, but you should have a look at the Win32 SDK sample "switcher". It's using CreateDesktop & co.

Note: You [obviously] need an NT kernel based OS for this.

generic_user_id17-Apr-02 11:10

generic_user_id

17-Apr-02 11:10

Thanks for the feedback, but I was looking for something that would work on both NT and 9x.

There are quite many apps out there that work on 95/98, so it must be possible. As the apps are fairly small I guess it doesn't take an awful lot of code to make it work.

I'll keep searching, if you got an idea please tell me.

Thanks in advance

Mike Nordell17-Apr-02 11:59

17-Apr-02 11:59

In Win9x it's completely unsupported. I've seen references to apps being _really_ ugly and to "switch desktop" they just grab a handle to any other apps window and move it to e.g. "appWnd.currpos - screenWidth", but I'd say yo get no friends from that approach even that it appears to work.

Now you know how some others do it. I just hope you don't do it yourself...

And even if you do, you'd have to track e.g. ALT+TAB to either not display the apps on "another desktop", or to swith desktop when alt-tabbing to an app on "another desktop".

A CPropertySheet, a CPropertyPage and a thread. Oh dear.

generic_user_id18-Apr-02 4:02

generic_user_id

18-Apr-02 4:02

Okay, thanks.

I guess I have to do it in the dirty way, as there appears to be no proper solution.

But as the desktop is a class of some sort it should be possible to create an array of them. I wonder why it isn't an array of desktops in the first place....

17-Apr-02 9:22

Hello there,

This isn't so much a problem (because I've got a solution for it) but I would like to know why it has happened in the first place. I've made use of a CPropertySheet control in one of my applications, it has two tabs (CPropertyPages) on it inherited from dialogues as CPropPage1 and CPropPage2 etc., pretty standard MFC via MSDN stuff. The sheet is constructed using AddPage (I think it's called that) not member variables in the CPropertySheet, everything works just perfectly, it constructs, shows and all the controls work great.

Now, when a button on the first property page is clicked, some extended processing needs to occur so I launch a worker thread and do some work. This works great too. Recently I added some options on the second property page and needed to make use of them during the extended processing thread on the first property page - still with me?

I wrote code (quickly guestimated) something like this:

void PropPage1::ButtonClick()
{
AfxBeginThread( Thread, this );
}

UINT Thread(LPVOID pParam)
{
CPropPage1 *caller = (CPropPage1 *)pParam;
CPropPage2 *options = NULL;
CPropertySheet *parent = NULL;

if(caller)
{
parent = (CPropertySheet *)GetParent();
if(parent) options = parent->GetPage(1);
... on and on - the rest doesn't matter.
}

return( preset_errorcode_from_somewhere );
}

Does that look OK? The reason I stop here is because at the "..." I get an Access Violation from CPropertySheet::GetPage(...) - the exact violation is from a CPtrArray I believe. No matter how many variations I do on this code, the same thing always happens. I might add that GetPageCount() correctly returns 2 indicating that there are two pages available.

The EXACT same code does not crash, if it is called from the CPropPage1::ButtonClick() handler instead of the worker thread. Now I'm aware that the code isn't exactly thread safe Wink | ;)

but should it really be crashing? I aren't aware of the behind the scenes operation, but obviously something is crossing a boundary somewhere. Why? My solution was to pass pointers to the PropertyPages via a structure into the thread and that works fine. The problem would seem to be a fault with the way GetPage(...) works because all of the other CPropertyPage members appear to function perfectly.

Just curious to know if anyone has a potential explanation for this behaviour?
Jon.

Re: A CPropertySheet, a CPropertyPage and a thread. Oh dear.

Joaquín M López Muñoz17-Apr-02 9:57

Re: Combo Box Uneditable?

17-Apr-02 9:57

The problem is a very frequent one, and stems from the fact that CWnd-derived objects do funny things across threads. The explanation is a little long, please bear with me:
Given a Cwnd, its associated HWND handle is simply stored in the m_hWnd member. The other way around, obtaining the associated CWnd from a given HWND, is not that simple. There's no easy way to have Win32 store some pointer to the CWnd inside the data hold for a particualr HWND. To work around this problem, MFC guys decided to keep a global map of HWNDs to CWnd pointers. Now comes the key point: for historical and performance reasons, this HWND to CWnd map is not unique, but instead each thread has its own, stored in so called thread local storage (TLS). In your particular case, the worker thread is given a pointer to CPropPage. So far so good. But when GetParent is called, the following sequence of events happen:

Win32 ::GetParent is called, returning a valid HWND.
The associated CWnd is sought for, and as there is none local to this thread, a mock-up one is created (and inserted into the map). This object is not the CPropertySheet you began with.

And the rest is easy. GetPage fails because it is issued on a CWnd constructed out of nothing, with no information about the original CPropertySheet (apart from being associated to the same HWND.)
Calls to methods of caller will work OK nevertheless, as this time caller is actually the real object.
The moral of this story is: don't pass CWnd pointers across threads.

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

Combo Box Uneditable?

17-Apr-02 9:06

How can I make a Combo Box uneditable. ie The user will not be allowed to type characters into it, only select something from the list

Shog⁹17-Apr-02 9:10

Shog⁹

17-Apr-02 9:10

use the CBS_DROPDOWNLIST style instead of CBS_DROPDOWN.

--------
Well actually they are sort of interesting

Nish, on Nudes

Re: Combo Box Uneditable?

17-Apr-02 9:14

Thanks a million!

CArchive, Serialization and Versions

Ted Christiansen17-Apr-02 8:44

Ted Christiansen

17-Apr-02 8:44

Hello,

The MSDN docs don't say how to respond when the serialization tries to serialized an unsupported version (see code snippet). Any ideas?

void MyObj::Serialize(CArchive& ar)
{
if (ar.IsLoading() == TRUE) {

int nVersion = ar.GetObjectSchema();

switch (nVersion) {
case 1:
ar >> m_id;
break;
// unknown version
default:
--> WHAT TO DO HERE????
break;
}
}
else {
ar << m_id;
}
}

Re: CArchive, Serialization and Versions

Mike Nordell17-Apr-02 8:47

Re: CArchive, Serialization and Versions

17-Apr-02 8:47

WHAT TO DO HERE????

Throw an exception?

Joaquín M López Muñoz17-Apr-02 8:58

17-Apr-02 8:58

MSDN doc about CArchive::Serialize features this interface:

virtual void Serialize( CArchive& ar );
throw( CMemoryException );
throw( CArchiveException );
throw( CFileException );

which means that the framework expects the method to throw any of the exceptions listed above. In your particular case, CArchiveException is the appropriate one to throw, with the m_cause member set to CArchiveException::badSchema.

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

MessageBox crash

17-Apr-02 8:40

I have an application that is very memory intensive being used with other applications that are also very memory intensive. I execute the code that allocates memory in a try/catch block so that I catch any problems that may occur. The problem is that when I try to display a message box to inform the user what happened, my application crashes when MessageBox ultimately calls AfxCallWndProc with a NULL pointer. After looking in wincore.cpp, I was able to see the problem is the FromHandlePermanent call in AfxWndProc returns NULL, and AfxCallWndProc proceeds to used that NULL pointer to call WindowProc. Since the window pointer is NULL, the WindowProc call crashes my app. Is there any way around this short of try/catching all of my AfxMessageBox calls???

Joaquín M López Muñoz17-Apr-02 8:42

17-Apr-02 8:42

Try using a raw call to Win32 MessageBox instead.

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

17-Apr-02 8:54

::MessageBox and AfxMessageBox both have the same problem.

Joaquín M López Muñoz17-Apr-02 9:00

17-Apr-02 9:00

How come? MessageBox cannot fail in MFC module wincore.cpp, as it has nothing to do with MFC.

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

17-Apr-02 9:30

That's what I thought. I tried using ::MessageBox(m_hWnd, "Error message...", "MyApp", MB_OK|MB_ICONEXCLAMATION). My application is an MFC dialog application and I get the following stack

AfxCallWndProc(CWnd * 0x00000000 {CWnd hWnd=???}, HWND__ * 0x01c305c0, unsigned int 134, unsigned int 0, long 21629170) line 215 + 3 bytes
AfxWndProc(HWND__ * 0x01c305c0, unsigned int 134, unsigned int 0, long 21629170) line 368
AfxWndProcBase(HWND__ * 0x01c305c0, unsigned int 134, unsigned int 0, long 21629170) line 220 + 21 bytes
USER32! UserCallWinProc@20 + 24 bytes
USER32! DispatchClientMessage@20 + 47 bytes
USER32! __fnDWORD@4 + 34 bytes
NTDLL! KiUserCallbackDispatcher@12 + 19 bytes
USER32! DispatchClientMessage@20 address 0x77e13974
USER32! MB_DlgProcW@16 + 23 bytes
USER32! UserCallWinProc@20 + 24 bytes
USER32! DefDlgProcWorker@20 + 129 bytes
USER32! DefDlgProcA@16 + 33 bytes
USER32! UserCallWinProc@20 + 24 bytes
USER32! CallWindowProcAorW@24 + 61 bytes
USER32! CallWindowProcA@20 + 25 bytes
_AfxActivationWndProc(HWND__ * 0x014a08f2, unsigned int 272, unsigned int 38734006, long 15133252) line 405
USER32! UserCallWinProc@20 + 24 bytes
USER32! SendMessageWorker@20 + 188 bytes
USER32! InternalCreateDialog@28 + 2472 bytes
USER32! InternalDialogBox@24 + 161 bytes
USER32! SoftModalMessageBox@4 + 1399 bytes
USER32! MessageBoxWorker@4 + 302 bytes
USER32! MessageBoxExW@20 + 82 bytes
USER32! MessageBoxExA@20 + 111 bytes
USER32! MessageBoxA@16 + 36 bytes
MyFunc() calls messagebox here!

Joaquín M López Muñoz17-Apr-02 9:37

17-Apr-02 9:37

Never thought about it! This (fascinating) stack dump shows that MessageBox is executed in the context of the local message pump. If one considers it carefully, it makes a lot of sense after all.
Well, if it's lack of memory what's causing the error in AfxCallWndProc (which I'm far from sure), you might try reserving some safeguard memory that is released on the catch block just before calling AfxMessageBox. Please tell us if this works (in case you decide to test it.)

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

Mike Nordell17-Apr-02 8:52

17-Apr-02 8:52

Try AfxGetMainWnd().