Yes the wab is OK. If you doubleclick it Windows asks if you want to import the addresses.
Somehow the WabOpen bit just thinks I want the default Wab (although there isn't one in Vista) and isn't getting the filename. In the original code there was a 'GetNativePath()' call which isn't available - could it be to do with how I'm passing in the file location string?
If i check the documentation (http://msdn.microsoft.com/en-us/library/ms629458%28v=vs.85%29.aspx[^]) for WAB_PARAM, the szFileName member is declared to be LPTSTR. This suggests that depending on your target options, it might be a unicode or an ansii/mbcs string which then suggests that there might be a unicode and an ansii/mbcs version of the function (as with a lot of API methods throughout windows). When you query the function's pointer...are you sure you are getting the correct version?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
I'm not sure - in the header file I can't see another version except WabOpenEx which I tried but didn't work.
I've noticed that my Contacts folder is actually receiving the wab addresses and getting bigger and bigger! So instead of opening the wab on its own it's adding them to the Contacts then opening those instead. Is this some undocumented Vista mechanism?
Thanks very much for everyone's conttributions so far.
While launching a MFC application(.exe) as OLE server, some time CWinApp::OnFileNew() gets failed; due to this frame window cannot be created and handle to the main window (m_pMainWnd) becomes NULL and error message "Error occurs in mfc42.dll" appeared.
At windows XP, CWinApp::OnFileNew() failed in 1 out of 100 times.
We have not implemented the OnFileNew() in our application; we are using default implementation of OnFileNew().
As per MSDN CWinApp::OnFileNew implements this command differently depending on the number of document templates in the application. If there is only one CDocTemplate, CWinApp::OnFileNew will create a new document of that type, as well as the proper frame and view class.
Problem occurs only at one system and frequency is one out of 100 and error message "Error occurs in mfc42.dll" appeared.
From your information it is rather impossible to guess what is wrong. But I will give you some notes that may help you to find the problem or enhance your question:
"Error occurs in mfc42.dll" seems to be an application specific error message (googling the exact term gives only a few results). So you should be able to locate the executed source sections before the error occurs.
Even when using the default implementation of OnFileNew(), virtual functions of your document class are involved. In this case I would especially check OnNewDocument(). When this returns FALSE, creation of the document and frame window will be stopped (see the MFC sources for CSingleDocTemplate::OpenDocumentFile()).
I ran into a small problem using Visual Studio 2012 Update 1.
Any MFC dialog that has controls with icons or bitmaps does not show the graphics if it is the first one in z-order. The following controls are displayed correctly.
A simple way to demonstrate this bogus behavior is to generate a dialog application with a couple of MFC EditBrowse Controls (but you could use MFC Buttons with icons as well). You can arbitratily change the z-order of the controls with the result that the icon does not display for the first one (preview is ok but not the compiled application).
I don't know whether this problem occurs in other versions of VS or if I have overlooked something important like proper initialization.
A simple way to get around this problem is to add a control with a picture at z-order 1 and make it invisible such that subsequent controls are not affected.
Your question is pretty valgue as there are a lot of RTOS's out there. A guess, is to put the function in its own thread and make the thread a higher priority than all others so it would not be preempted. Prioritization can be a tricky business though.
HOW the RTOS you are using schedules threads is very important. Many (most?) RTOSs can't actually guarantee a function's run time; they simply run fast enough that with proper programming you can get close enough. Something that takes over 10ms will almost always fall into this latter category since writing a function to use such an exact amount of time is essentially impossible (hardware interrupts alone on embedded system will add enough variance to cause a measurable difference in timings.)