VS2010 and HINSTANCES
in [MFC]
|
From: David Webber on 3 Jun 2010 04:53 "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message news:O5rIQRnALHA.4400(a)TK2MSFTNGP05.phx.gbl... > However, as my project expands, I find I am trying to pass an hInst which > the system has cunningly initialised to > > 0xcccccccc; > Thanks for the assorted answers. Yes I know that 0xcccccccc means it is uninitialised, and I *am* working on getting it initialised, but while doing that I wanted to try and make my code more fail-safe. A quick way of testing the validity of an an HINSTANCE before passing it to AfxSetResourceHandle() - something equivalent to what IsWindow() does for HWNDs - would have been ideal. [Yes Joe that was my question: I wasn't asking *why* it was 0xcccccccc or asking you to debug my code (this time <g>), so I didn't omit any essential information. Nevertheless (unlike others it seems) I forgive your crustiness, as I too belong to the grumpy-old-men club. But I specifically wasn't asking "My program doesn't work, Can you tell me what I did wrong?" I was asking "It would be cool to test for invalid instance handles - is there a quick way?"] //--- The story: In view of the interest, I'll explain how I got here. As explained in other recent threads, my 'solution' from VS 2008 did not import properly into VS 2010 - it wouldn't run on a machine without VS 2010. Even after I got rid of even the most oblique references to MFC9 in code, resources, and manifests. So I have created a new solution, and am importing old code into it carefully. It has been nearly a week so far and my document is not drawing itself yet. :-( The resource handle stuff stems from a class I have which manages them for the purpose of loading menus, dialogues, strings in different foreign languages from resource-only DLLs. It has a static HINSTANCE member which is that of the language resource DLL which has been chosen, or NULL for English. If it is non-NULL the constructor calls AfxGetResourceHandle(), and stores the result in a (non-static) member, and sets the language DLL's static resource handle with AfxSetResourceHandle(). The destructor sets the old one back again. (In between other members of this class wrap all my dialogue handling.) It is quite elegant and has worked beautifully and transparently. The static handle to the language DLL *is* initialised to NULL where the static member is declared. But that may not be happening - static stuff isn't always initialised when you declare static MYCLASS::x = 0; We'll see. But it is the destructor which is trying to reset an uninitialised handle, so I'm not yet sure. In my new solution, I thought I'd take advantage of zappy new project possibilities - specifically a tabbed MDI interface with a navigation pane down the left (not sure about the calendar though). Long before the program knows about View windows, it is initialising the navigation pane. Somewhere in the middle of this, my resource handle manager class is getting called (to try and set the "Folders" title in the new navigation pane to the desired language"), and it is only initialised later. (I haven't looked at the initialisation didn't explicitly ask it to do this, but clearly my MainFrame code knows better than I do that this would be wanted.) I am not sure (I'll find out after breakfast) if AfxGetResourceHandle() is returning 0xcccccccc - hope not, it wouldn't seem logical - or if it is screwing up in some other way, but *of course* I'll try and put a stop to it. //------ Back to the initial point: Meanwhile, as I say, it would be defensive programming to have if( IsValidHinstance(hInst) ) AfxSetResourceHandle( hInst ); instead of if( hInst ) AfxSetResourceHandle( hInst ); This would mean folk wanting other languages would get their menus in English, instead of a program crash. That was all I was asking. The answers here seem to indicate that there might not be one - I didn't find it in the help system either, though I'm finding it more difficult than ever to find anything in the VS 2010 help system. (Which is maybe why no-one has categorically said that there isn't one <g>.) Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm
From: David Lowndes on 3 Jun 2010 05:52 >Meanwhile, as I say, it would be defensive programming to have > >if( IsValidHinstance(hInst) ) AfxSetResourceHandle( hInst ); > >instead of > >if( hInst ) AfxSetResourceHandle( hInst ); > >This would mean folk wanting other languages would get their menus in >English, instead of a program crash. That was all I was asking. > >The answers here seem to indicate that there might not be one I don't think there is, other than to try using the module/instance handle value somehow and check if it fails. >I didn't >find it in the help system either, though I'm finding it more difficult than >ever to find anything in the VS 2010 help system. Once again the help experience keeps getting worse. :) Dave
From: David Ching on 3 Jun 2010 07:40 "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message news:OHAD2ovALHA.1700(a)TK2MSFTNGP02.phx.gbl... > The static handle to the language DLL *is* initialised to NULL where the > static member is declared. But that may not be happening - static stuff > isn't always initialised when you declare > > static MYCLASS::x = 0; > > We'll see. But it is the destructor which is trying to reset an > uninitialised handle, so I'm not yet sure. > Initializing static variables has worked reliably for me. But the 0xcccccccc is said to be used for *local* variables, not static members. I'm not sure if that is significant, but it may mean the scope of your variable is not what it appears to be? > In my new solution, I thought I'd take advantage of zappy new project > possibilities - specifically a tabbed MDI interface with a navigation pane > down the left (not sure about the calendar though). Long before the > program knows about View windows, it is initialising the navigation pane. > Somewhere in the middle of this, my resource handle manager class is > getting called (to try and set the "Folders" title in the new navigation > pane to the desired language"), and it is only initialised later. (I > haven't looked at the initialisation didn't explicitly ask it to do this, > but clearly my MainFrame code knows better than I do that this would be > wanted.) I am not sure (I'll find out after breakfast) if > AfxGetResourceHandle() is returning 0xcccccccc - hope not, it wouldn't > seem logical - or if it is screwing up in some other way, but *of course* > I'll try and put a stop to it. > I would set a breakpoint in your resource class and view the callstack when it is accessed the first time to see if you can call your Init method prior to all this starting. It would seem one of the first things to do in your InitInstance(). You could also set a data breakpoint on the static hInst variable changing. > //------ > Back to the initial point: > > Meanwhile, as I say, it would be defensive programming to have > > if( IsValidHinstance(hInst) ) AfxSetResourceHandle( hInst ); > > instead of > > if( hInst ) AfxSetResourceHandle( hInst ); > > This would mean folk wanting other languages would get their menus in > English, instead of a program crash. That was all I was asking. > > The answers here seem to indicate that there might not be one - I didn't > find it in the help system either, though I'm finding it more difficult > than ever to find anything in the VS 2010 help system. (Which is maybe > why no-one has categorically said that there isn't one <g>.) > I looked very hard but couldn't find one. I think once I wrote something like: if ( hInst && hInst != 0xcccccccc ) AfxSetResourceHandle(hInst); Which fixed my logic but of course I went back and cleaned that up prior to shipping. BTW, does your code work OK in Release mode (where uninitialized variables are left uninitialized and not set to 0xcccccccc)? I would think it would work randomly well based on whether hInst happened to be initialized to 0 or not. -- David
From: David Webber on 3 Jun 2010 08:30 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:A4B0B11D-7081-4A87-B8AB-072F221E1E76(a)microsoft.com... > Initializing static variables has worked reliably for me.... There *are* circumstances when it doesn't, but not very often. Nevertheless I've been caught by it and am wary. However it is all fixed now,... > But the 0xcccccccc is said to be used for *local* variables, not static > members. I'm not sure if that is significant, but it may mean the scope of > your variable is not what it appears to be? .... and it wasn't that. > I would set a breakpoint... Yes. Among other places, I set a breakpoint in some initialisation code, and found it wasn't being called. The missing initialisation was actually in a DLL. Searching for references to it in the VS 2008 code and the VS 2010 revealed a line I had inadvertently over looked in the DllMain (telling it to remember its hInstance in a static class variable). The variable I should have been initialising was therefore NULL (as it was declared so) and code which included if( hInstance) { ... } was failing to run, resulting in another local hInstance NOT being initialised, resulting in the problem. I now have written out 1000 times: "When creating a new MFC solution and importing old code, check very carefully ALL the functions which the App Wizard provides for you! Especially DllMain!" > I looked very hard but couldn't find one. I think once I wrote something > like: > > if ( hInst && hInst != 0xcccccccc ) > AfxSetResourceHandle(hInst); I wondered about that, but explicitly checking for 0xcccccccc seemed wrong. I immediately think that in the next version of the compiler, the debugger might initialise to 0xabcdabcd or some other number, and start worrying about hostages to fortune. Now if there was something like #define UNINITIALISED_VARIABLE 0xcccccccc in the Microsoft headers, I'd consider it fair game to check against UNINITIALISED_VARIABLE (especially inside passages with _DEBUG defined). I haven't checked to see if there is such a thing. > Which fixed my logic but of course I went back and cleaned that up prior > to shipping. BTW, does your code work OK in Release mode (where > uninitialized variables are left uninitialized and not set to 0xcccccccc)? > I would think it would work randomly well based on whether hInst happened > to be initialized to 0 or not. It would have crashed, but I found the bug before checking the release version. Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm
From: David Ching on 3 Jun 2010 10:50 "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message news:uQeA$lxALHA.1892(a)TK2MSFTNGP05.phx.gbl... > Glad you got it working! :-) > I now have written out 1000 times: > > "When creating a new MFC solution and importing old code, check very > carefully ALL the functions which the App Wizard provides for you! > Especially DllMain!" > Did you use Copy/Paste? ;) > Now if there was something like > > #define UNINITIALISED_VARIABLE 0xcccccccc > > in the Microsoft headers, I'd consider it fair game to check against > UNINITIALISED_VARIABLE (especially inside passages with _DEBUG defined). > I haven't checked to see if there is such a thing. Frankly, I think the reason they don't have this or any function to check for the value is that we're not supposed to even know about it, it's just supposed to be something that when it breaks in the debugger, we see the strange value and go "ah ha!" > It would have crashed, but I found the bug before checking the release > version. > So it wouldn't have helped to check for UNINITIALISED_VARIABLE anyway. -- David
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Heap stack Class questons Next: Format of the What's This Popup Help Text file |