When my program attempts to generate an AFX_IDP_PARSE_REAL error for the user, it fails to load the string that is stored in the afxres.rc file. I found this question already, however it was solved because the reference to afxres.rc was accidentally deleted from the program.rc file. That is not the case for me. My program.rc file includes the exact code listed in the answer to include the afxres.rc file.
In debug mode, it breaks on the ASSERT below.
int AFXAPI AfxMessageBox(UINT nIDPrompt, UINT nType, UINT nIDHelp)
{
CString string;
if (!string.LoadString(nIDPrompt))
{
TRACE(traceAppMsg, 0, "Error: failed to load message box prompt string 0x%04x.\n", nIDPrompt);
ASSERT(FALSE);
}
if (nIDHelp == (UINT)-1)
nIDHelp = nIDPrompt;
return AfxMessageBox(string, nType, nIDHelp);
}
When I am actually running the application via the .exe, it simply generates an empty warning box since the AFX_IDP_PARSE_REAL string is not loaded; this goes for any string in the afxres.rc.
What could cause the application to not load the string from the afxres.rc?
Just letting you know that it is not enough to include the afxres.rc file normally, the way you include header files into cpp/h files. You actually need to include it twice. If you create a brand new MFC project and check the code of an rc file (using "View Code" option) you would notice that there is a normal include:
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "afxres.h"
and there is a TEXTINCLUDE section inside the rc file:
2 TEXTINCLUDE
BEGIN
"#include ""afxres.h""\r\n"
"\0"
END
You need to make sure you do the same thing in your project. Alternatively, you can use a "Resource Includes" wizard that is available via right click on the Resource View that allows editing the both sections via the dialog box:
Related
I have code that was first developed with Visual C++ Version 1.52 (working and self taught). I am now trying to convert it to a Visual Studio project. It is a single module project written with MFC. I used the 'project from existing code' option to generate the project which executes just fine but for loading bitmap resources. I tested the same relevant code (LoadBitmap and LoadImage) in MFC multi-module projects code and they work just fine. I am able to load bitmap files directly from disk. If I delete the bitmap files from the project there is 22k less size of the code. The total bitmap file size is 18k. The only error message that I get is '_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)'. I am assuming that the default is adequate. At this point I am thinking that it is a link properties issue because of MFC, but I don't know what that might be. Any ideas? Thank you.
//header
//
class CMainWindow : public CFrameWnd
{
public:
CMainWindow();
//{{AFX_MSG( CMainWindow )
afx_msg void OnPaint();
afx_msg void OnDestroy();
afx_msg void OnLButtonDown(UINT nFlags, CPoint point);
//}}AFX_MSG
//protected:
BOOL flag;
BOOL game, turn;
CWnd tictic1, tictic2, tictic3, tictic4, tictic5, tictic6, tictic7, tictic8, tictic9;
CRect RCT;
int id, count;
CBitmap O, X;
//body
//
CMainWindow::CMainWindow()
{
LoadAccelTable("MainAccelTable");
Create(NULL, "Tic Tac Toe\0",
WS_OVERLAPPEDWINDOW, rectDefault, NULL, NULL, 0, NULL);
flag = TRUE;
id = 0;
O.LoadBitmap(IDB_BITMAP1);
X.LoadBitmap(IDB_BITMAP2);
If I transplant the relevant code into VS generated MFC documents it works. The only difference is that all of my code is original Visual C++ Version 1.52 MFC code, in a single .cpp document but all the rest of the code seems to work fine.
Uh, when I has collecting observations for this query, I deleted the two relevant bitmap files from the resources in order the report the difference in file size. After I added them back in, the functions then work properly. I think that what I had originally done was when first importing the new resources, I tried selecting the two as a group and when they displayed right, in the resource file, I assumed that it had worked. It apparently didn't. Duh!
Uh, development; after cleaning up my code, I rebuilt it and it wouldn't load bitmap resources. I deleted the resources then installed them again and the program has worked since. So you tell me. I think that it's serendipitous. Duh!
I have a CString variable which is linked to a static text box inside one of my dialogs, lets call it controlVariable. When I click the START button inside this dialog a couple of things happen. First I update the contents of the controlVariable (to say something like "initialization begun"). I do UpdateData(FALSE) and then run an initialization of another class (which starts some threads). This initialization takes some time, so this is why the contents of the static text box need to reflect that while its running. But the changes aren't reflected until the OnBnClickedStart() function finishes. I'm having trouble having the changes to this controlVariable reflect in the dialog.
What I've tried:
UpdateData(FALSE) after changing the controlVariable using basic CString append functions (e.g. CString A = str1 + str2;) and changing the control variable using .format() (e.g. controlVariable.format(_T("some text")); )
Running OnPaint() after changing the controlVariable contents
I went into debug mode and the program runs into the BEGIN_MESSAGE_MAP section of the dialog class and just loops there until I step out of it. The contents of the static text box linked to my controlVariable aren't updated until I step out of BEGIN_MESSAGE_MAP. So the contents of my static text box don't even update at the end of my OnBnClickedStart() funciton.
Example Code:
CMyClass someClass;
CString controlVariable; // linked to some static text in the SomeDlgClass
void SomeDlgClass::OnBnClickedStart()
{
controlVariable = CString("System initialized\r\n"); // Also tried
UpdateData(FALSE); // Also tried OnPaint()
someClass.initialize(); // I would like the static text box to update before I run this
}
So when I'm running this, my main dialog seems like it's "frozen" - I can't move the window around or click any of the buttons. Suggestions?
Thanks.
I want to change property value to selected text in a dialog.
this is my sample source.
#include "ifx.h"
STRING outPath;
export prototype MyFunction(HWND);
function OnFirstUIBefore()
NUMBER nResult, nSetupType, nvSize, nUser;
STRING szTitle, szMsg, szQuestion, svName, svCompany, szFile, szDir;
STRING szLicenseFile;
BOOL bCustom, bIgnore1, bIgnore2;
begin
Dlg_SdAskDestPath:
nResult = SdAskDestPath(szTitle, szMsg, INSTALLDIR, 0);
if (nResult = BACK) goto Dlg_SdAskDestPath;
Dlg_AskOutPath:
nResult = AskDestPath(szTitle, szmsg, szDir, 0);
if (nResult = BACK) goto Dlg_SdAskDestPath;
outPath = szDir;
MyFunction(ISMSI_HANDLE);
return 0;
end;
function MyFunction(hMSI)
STRING value;
begin
MsiSetProperty(hMSI, "OutPutPath", outPath);
end;
OutPutPath used in custom action after finish install.
But OutPutPath was not changed when read in custom action.
I think I must not use ISMSI_HANDLE. But i don't know what i have to use instead.
I tried to make custom action which load Install scripts's method MyFunction after finish install.
It worked well, But the global variable outPath was nul..
Please teach me how can i do this if you know.
Thank you.
At a minimum, you must use a public property, that is one with a name that does not contain any lowercase letters. You may also have to list it in SecureCustomProperties in order to allow users to modify it, if you support installation in restricted environments.
However I'm not certain the exact scenario described by your comment:
I tried to make custom action which load Install scripts's method MyFunction after finish install.
If this scenario is truly after the end of the Windows Installer portion of the installation (an InstallScript MSI runs code both before and after), properties as a whole may not survive to do what you need. To support reading the value at that time you will have to consider other approaches, such as writing the value in the registry, or into a file (e.g. in SUPPORTDIR).
I have got a library which was made for a desktop windows project. It is done in MFC VC++ by somebody else, and it works correctly. I will use one particular function from the library as an example for explaining the situation.
The example function goes like this:
CString GetFulPath(); // .h file
In the cpp file,
CString CwFolderBrowser::GetFullPath()
{
CString path;
if(this->M_pIDLIST!=NULL)
{
LPTSTR fullPath=path.GetBuffer(MAX_PATH);
::SHGetPathFromIDList(this->M_pIDLIST, fullPath); //ITEMIDLISTからパスを得る
path.ReleaseBuffer();
}
return path;
}
Now, I can include this library in my project and do something like:
CwFolderBrowser cFolderBrowser;
if(cFolderBrowser.ShowDialog() == TRUE)
cPath = cFolderBrowser.GetFullPath();
This will show a folder browser dialog and let me choose a folder. It works fine on desktop windows.
Currently, I am working on Windows CE device. We have converted the library for use with Windows CE by removing unsupported functions and stuff. The library compiles and builds correctly without errors.
Next, I create an MFC Smart Device project, include the converted library, its h file and lib files and set the proper directories for dlls. The project builds fine. I can #include the library's h file properly too.
The problem arises as soon as I call the GetFullPath function:
cPath = cFolderBrowser.GetFullPath();
It gives me an unresolved external link error! The Intellisense does show this function in its list and I can choose it and everything. But in vain.
Strangely, If I modify the library and change GetFullPath()'s signature as below,
LPCTSTR GetFulPath(); // .h file LPCTSTR instead of CString
In the cpp file,
LPCTSTR CwFolderBrowser::GetFullPath() // Return type changed to LPCTSTR
{ // instead of CString
... // Body modified accordingly
}
then, the unresolved external Link error disappears and it works!
I am stumped about this strange behaviour, because, I can use CString normally in the MFC Smart Device project and there are no errors. The link error shows up only when I try to call functions from the library (and other such libraries) dll. At the same time, BOOL, int etc. seems to have no problems as function return types.
Ofcourse, I can go through each library and change every instanceof a CString return to LPCTSTR, but that would be a very big change. I would like to know why CString works fine in project as well as dll when on desktop, while, on Win CE, it works in the project but not i the DLL (At the same time, the DLL itself compiles fine without errors wether it uses CString or LPCTSTR!).
So, basically, I would like to keep the function CString if possible, and would like to know the reason why this happens. The exact same error also happenes in other libraries too.
Any help is appreciated. Thank you.
UPDATE:
I saw a page on ATL & MFC 7.0 which said about using the /Zc:wchat_t option. I have checked the Dll project as well as my application. Both use the same option of 'Treat wchar_t as Built-in type' as Yes. So, that option matches up.
Further, as I mentioned above, changing the function return to LPCTSTR works. The error disappears. Everything is going fine until I convert the returned LPCTSTR back to CString. The CString turns out as empty/Null. This happens both inside the dll code itself, as well as in my application code too.
UPDATE2:
Thanks to Michael and Cody, I changed the function to LPCTSTR and made sure that the values were not going out of scope before I could use them like they suggested. Now the empty/Null problem is solved and I can get the path values properly.
The problem that remains is that I have to convert all the CString functions to LPCTSTR, which is not exactly feasible. I would like to keep the functions as CString.
This is a classic problem and has been asked often here on SO.
This cannot work:
LPCTSTR CwFolderBrowser::GetFullPath()
{
CString path;
if(this->M_pIDLIST!=NULL)
{
LPTSTR fullPath=path.GetBuffer(MAX_PATH);
::SHGetPathFromIDList(this->M_pIDLIST, fullPath);
path.ReleaseBuffer();
}
return (LPCTSTR)path; // << here you return a pointer to the zero
// terminated string in the path object,
} // but path will be deleted as soon as it goes
// out of scope
Maybe in some cases the function appears to work because the memory of the deleted CString object has not yet been overwritten.
You should do this (no error treatment here for simplicity):
LPCTSTR CwFolderBrowser::GetFullPath(TCHAR *pathbuffer)
{
if(this->M_pIDLIST!=NULL)
{
::SHGetPathFromIDList(this->M_pIDLIST, pathbuffer);
}
return (LPCTSTR)pathbuffer;
}
...
// call like this
TCHAR pathbuffer[MAX_PATH];
GetFullPath(pathbuffer);
I'm working with a third party COM server with its own custom interface that sets and gets structs as some of its properties. As it happens I'm using C++ for the client. I've posted some representative code from the IDL file below with names changed and GUIDs removed.
Is the packing of the structure defined or is it just good fortune that my client code happens to use the same packing settings that the COM server was built with? Would it be likely to go wrong in projects where the default C++ compiler packing settings had been changed? Is there a pragma pack setting that I could use to make sure the client compiler packing settings are correct?
I can't see any packing pragmas or statements in either the IDL or the header file generated from MIDL. What would happen if the client was in C# or VB instead? Is the packing behaviour more clearly specified if called via the IDispatch mechanism?
struct MyStruct
{
int a, b;
};
[
object,
uuid( /* removed */ ),
dual,
nonextensible,
pointer_default(unique)
]
interface IVideoOutputSettings : IDispatch{
[propget, id(1), HRESULT MyProperty([out, retval] struct MyStruct* pVal);
[propput, id(1), HRESULT MyProperty([in] struct MyStruct newVal);
/* other methods */
};
The default packing is along 8-byte boundaries, according to the MIDL command line switch reference here:
/Zp switch # MSDN (MIDL Language Reference)
Other parts of your code are more likely to break first if the pack value is changed, as the IDL file is usually pre-compiled ahead of time, and it is rare that someone will deliberately alter the command line switches given to MIDL (but not so rare that someone could fiddle with the C-scope #pragma pack and forget to restore the default state).
If you have a good reason to alter the setting, you can explicitly set the packing with a pragma pack statement.
pragma Attribute # MSDN (MIDL Language Reference)
It is pretty good fortune that no party has changed any setting that would interfere with the default packing. Can it go wrong? Yes, if someone goes out of their way to change the defaults.
When using an IDL file, the details are typically compiled into a typelib (.tlb), and it is assumed that the platform are the same for both servers and clients when using the same typelib. This is suggested in the footnotes for the /Zp switch, as certain values will fail against certain non-x86 or 16-bit targets. There can also be 32bit <-> 64bit conversion cases that could cause expectations to break. Unfortunately I don't know if there are even more cases out there, but the defaults do work with minimal fuss.
C# and VB do not have any intrinsic behavior to handle information in a .tlb; instead, a tool like tlbimp is typically used to convert COM definitions into definitions usable from .NET. I can't verify whether all expectations succeed between C#/VB.NET and COM clients and servers; However, I can verify that using a specific pragma setting other than 8 will work if you reference a .tlb that was created from an IDL compiled under that setting. While I wouldn't recommend going against the default pragma pack, here are the steps to perform if you'd like a working example to use as a reference. I created a C++ ATL project and a C# project to check.
Here are the C++ side instructions.
I created an ATL project called SampleATLProject with the default settings in Visual Studio 2010, no fields changed. This should create a dll project for you.
Compiled the project to assure that the proper C-side interface files are being created (SampleATLProject_i.c and SampleATLProject_i.h).
I added an ATL Simple Object called SomeFoo to the project. Again, no defaults were altered. This creates a class called CSomeFoo that is added to your project.
Compile SampleATLProject.
I right-clicked the SampleATLProject.idl file, then under the MIDL settings, set the Struct Member Alignment to 4 bytes (/Zp4).
Compile SampleATLProject.
I altered the IDL to add a struct definition called 'BarStruct'. This entailed adding a C-style struct definition with the MIDL uuid attribute, and an entry in library section referencing the struct definition. See snippet below.
Compile SampleATLProject.
From the Class View, I right-clicked on ISomeFoo and added a method called FooIt, that takes a struct BarStruct as an [in] parameter called theBar.
Compile SampleATLProject.
In SomeFoo.cpp, I added some code to print out the size of the struct and throw up a Message Box containing the details.
Here is my IDL for the ATL project.
import "oaidl.idl";
import "ocidl.idl";
[uuid(D2240D8B-EB97-4ACD-AC96-21F2EAFFE100)]
struct BarStruct
{
byte a;
int b;
byte c;
byte d;
};
[
object,
uuid(E6C3E82D-4376-41CD-A0DF-CB9371C0C467),
dual,
nonextensible,
pointer_default(unique)
]
interface ISomeFoo : IDispatch{
[id(1)] HRESULT FooIt([in] struct BarStruct theBar);
};
[
uuid(F15B6312-7C46-4DDC-8D04-9DEA358BD94B),
version(1.0),
]
library SampleATLProjectLib
{
struct BarStruct;
importlib("stdole2.tlb");
[
uuid(930BC9D6-28DF-4851-9703-AFCD1F23CCEF)
]
coclass SomeFoo
{
[default] interface ISomeFoo;
};
};
Inside the CSomeFoo class, here is the implementation for FooIt().
STDMETHODIMP CSomeFoo::FooIt(struct BarStruct theBar)
{
WCHAR buf[1024];
swprintf(buf, L"Size: %d, Values: %d %d %d %d", sizeof(struct BarStruct),
theBar.a, theBar.b, theBar.c, theBar.d);
::MessageBoxW(0, buf, L"FooIt", MB_OK);
return S_OK;
}
Next, on the C# side:
Go to the debug or desired output directory for SampleATLProject and run tlbimp.exe on the .tlb file generated as part of the C++ project output. The following worked for me:
tlbimp SampleATLProject.tlb /out:Foo.dll /namespace:SampleATL.FooStuff
Next, I created a C# console application, and added a reference to Foo.dll to the project.
In the References folder, go to the Properties for Foo and turn off Embed Interop Types by setting it to false.
I added a using statement to reference the namespace SampleATL.FooStuff as given to tlbimp, added the [STAThread] attribute to Main() (the COM apartment models have to match for in-proc consumption), and added some code to call the COM component.
Tlbimp.exe (Type Library Importer) # MSDN
Here is the source code for that console app.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using SampleATL.FooStuff;
namespace SampleATLProjectConsumer
{
class Program
{
[STAThread]
static void Main(string[] args)
{
BarStruct s;
s.a = 1;
s.b = 127;
s.c = 255;
s.d = 128;
ISomeFoo handler = new SomeFooClass();
handler.FooIt(s);
}
}
}
Finally, it runs and I get a modal popup with the following string displayed:
Size: 12, Values: 1 127 255 128
To be sure that a pragma pack change can be made (as 4/8 byte packing are the most common alignments used), I followed these steps to change it to 1:
I returned to the C++ project, went to the properties for SampleATLProject.idl and changed the Struct Member Alignment to 1 (/Zp1).
Recompile SampleATLProject
Run tlbimp again with the updated .tlb file.
A warning icon will appear on the .NET File Reference to Foo, but may disappear if you click on the reference. If it doesn't, you can remove and re-add the reference to the C# console project to be sure it is using the new updated version.
I ran it from here and got this output:
Size: 12, Values: 1 1551957760 129 3
That's weird. But, if we forcefully edit the C-level pragma in SampleATLProject_i.h, we get the correct output.
#pragma pack(push, 1)
/* [uuid] */ struct DECLSPEC_UUID("D2240D8B-EB97-4ACD-AC96-21F2EAFFE100") BarStruct
{
byte a;
int b;
byte c;
byte d;
} ;
#pragma pack(pop)
SampleATLProject is recompiled here, no changes to the .tlb or .NET project, and we get the following:
Size: 7, Values: 1 127 255 128
Regarding IDispatch, it depends on whether your client is late-bound. Late-bound clients have to parse the type information side of IDispatch and discern the proper definitions for non-trivial types. The documentation for ITypeInfo and TYPEATTR suggests that it is possible, given that the cbAlignment field provides the information necessary. I suspect most will never alter or go against the defaults, as this would be tedious to debug if things went wrong or if the pack expectations had to change between versions. Also, structures are not typically supported by many scripting clients that can consume IDispatch. One can frequently expect that only the types governed by the IDL oleautomation keyword are supported.
IDispatch interface # MSDN
IDispatch::GetTypeInfo # MSDN
ITypeInfo interface # MSDN
TYPEATTR structure # MSDN
oleautomation keyword # MSDN
Yes, structs are a problem in COM. If you use IUnknown based interfaces then you'll have to roll the dice with proper compiler settings. Few reasons to change the default.
If you use COM Automation then you have to declare the struct with a typedef in the .IDL. So that the client code can use IRecordInfo to access the structure properly, guided by the type library info. All you have to do is ensure that your compiler's /Zp setting matches midl.exe's /Zp setting. Not hard to do.
You sail around the problem entirely by realizing that any structure can be described by an interface with properties. Now it doesn't matter.