|
I dont know what you have done, but I would do this because it works:
open the source *.rc file and search the IDD_* stuff of the dialog,
and copy it to the target *.rc file. Do the same with the Control IDs and so an.
To make it work you need some code: write new stuff, or copy it.
Greetings from Germany
|
|
|
|
|
If it compiles OK but the dialog doesn't appear, the dialog resource cannot be found. Make sure the IDD_xxxx in the .rc is the same one in the dialog .h header file.
|
|
|
|
|
Hello All
This is my first experience in win32 programming, and i am wondering how to change the language of the messagebox buttons, i had tried to make it in Arabic, and i had used this code
DWORD dd=MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_EGYPT);
MessageBoxEx(NULL,TEXT("æäÏææÒ"),TEXT("æäÏææÒ"),
MB_OK|MB_ICONEXCLAMATION|MB_RTLREADING|MB_RIGHT,dd);
but it is still make the text of the button is "OK" instead of the equivalent Arabic text!
|
|
|
|
|
What OS are you using?
Have you enumerated the locales to make sure that the Arabic locale is installed on the machine?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
i am using Windows XP Professional, Service Pack 2
|
|
|
|
|
Then MessageBoxEx() should work correctly.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi all,
I'm having a class called SRecordset, which will be derived from CObject class.
I would like to do that create a dll file for SRecordset class. So please tell me which one is the best choice from the below two.....
1) MFC Extension Dll
2) MFC Regular Dll
Thanks in advance
|
|
|
|
|
If you make an MFC extension DLL, then it cannot be used by non-MFC applications. Regular MFC dll can be used by non-MFC applications too. Now, it depends on your requirements to choose one of the two.
"The difficulty lies, not in the new ideas, but in escaping from the old ones."
-- John Maynard Keyes, 1936
|
|
|
|
|
ok fine but some functions of my class(SRecordset) having arguments,which is like as objects of MFC class's ie.) CDatabase,CString,CArchive...etc.So please which one is the best.....
|
|
|
|
|
If you ask my opinion, or if your DLL has to be used by non-MFC applications too, then choose regular MFC dll.
"The difficulty lies, not in the new ideas, but in escaping from the old ones."
-- John Maynard Keyes, 1936
|
|
|
|
|
i need your opinion....
Some documents explains that you couldn't pass MFC object as a function parameter when you will create your dll by using regular dll...
|
|
|
|
|
If you make regular MFC DLL, the caller cannot send or receive pointers/references to MFC objects/MFC classes . If you intend to use MFC objects at interfacing level, then you must choose MFC extension DLLs. But do note that if you write an MFC extension DLL, then, only MFC applications will be able to make use of your DLL. If you do not plan to use this DLL with any non-MFC application, then go head and write your MFC extension DLL.
"The difficulty lies, not in the new ideas, but in escaping from the old ones."
-- John Maynard Keyes, 1936
|
|
|
|
|
ok if i will create a mfc regular dll, i can't pass CArchive reference to dll function...i am correct.......
|
|
|
|
|
surezu wrote: ok if i will create a mfc regular dll, i can't pass CArchive reference to dll function...i am correct.......
Yes. You will need to create an MFC extension DLL for that.
|
|
|
|
|
|
myself i always go for regular mfc dll
saves time and hassle plus you never know what you might want to use it for in the future.
does depend on the spec but to keep things simple use regular dll
|
|
|
|
|
I have a dll which builds fine on my development machine in both debug as well as release build.
I install the application on my test machine which is a different build from what I had build the code from. Due to the installation the files(exe and dll) gets copied into the application folder.
Now I copy the files that I had got from building my project to the test machine and try to register the dll. The dll gets registered in the release build but not in the debug build.
Error: The dll has failed to register. The application has failed to start because the application configuration is wrong. Reinstallign teh application may fix the machine.
Please let me know what could be the reason.
|
|
|
|
|
You have probably run vcredist_x86.exe on the target machine ? I am right ?
This install only the release version of the libraries (you cannot distribute debug version of your program). That's probably the reason why it works in release but not in debug mode.
|
|
|
|
|
What implication will running vcredist_x86 will have?
Anyway i'm installing a larger application that contains my release dll as a part?
I'm copying the debug dll that I get from building the same application where I have made some changes. Later when i copy the debug dll to the test machine installer folder but I could not register the dll. I think I'm right that unless the dll gets registered it shall not be recognized for debugging.
Do project settings play a role here?
|
|
|
|
|
tom groezer wrote: What implication will running vcredist_x86 will have?
It install the C runtime libraries and MFC libraries, but of course, only the release versions of these libraries.
tom groezer wrote: I think I'm right that unless the dll gets registered it shall not be recognized for debugging.
I don't agree: when you register it, the dll will be loaded and a specific function of it will be called. In your case, loading the dll will fail because the debug versions of the dll's it use are not found.
|
|
|
|
|
Thanks for the reply.
Do u mean to say that the since I have the release version of my C runtime library the debug version of the dll is not getting registered?
Is there any way that I could register the debug dll on my test machine? What would be the way out. Please elaborate.
|
|
|
|
|
I'm saying that your debug dll uses the debug version of the C runtime library (and MFC if it uses MFC). Running vcredist_x86.exe will only install the release version of these libraries. So, when you try to load your dll, it will fail. And, for registering the dll, you need to load it. So, yes, the registration will fail.
I have a question: did you run vcredist_x86.exe yourself on the machine ? If no, then maybe it is already installed (then you have to take care if you instal your program on a machine that doesn't have it installed) or you statically link to the libraries.
tom groezer wrote: Is there any way that I could register the debug dll on my test machine?
Why would you do that ? Is there any specific reason for that ? Do you know that distributing debug versions of your program is not allowed ?
Anyway, did you try to statically link agains MFC libraries and the C runtime library ?
For the latter, go into your project settings -> "C/C++" -> "Code Generation" and set "Run-time library" to "Multi-threaded Debug".
By the way, can you check this same setting for the release version of your dll and tell me what it is ?
|
|
|
|
|
Hi all,
I have some problems by printing from my application. The first is that I have to avoid the user choosing page's orientation, I have found one Roger Allen's article (http://www.codeproject.com/printing/customprintdialog.asp[^]) and I think I have understood it right, so it won't be a problem. Then, setting the orientation that every view needs I had the problem that it only worked at the second time, it now works good thanks to this forum and some answers that I found during today. But there is something that I don't understand.
One example says:
if (bRet)
{
DEVMODE *pDevMode = (DEVMODE*)::GlobalLock(m_hDevMode) ;
pDevMode->dmOrientation = DMORIENT_LANDSCAPE ;
::GlobalUnlock(m_hDevMode) ;
}
And the code I have used (found here too) is:
void CMyView::OnPrepareDC(CDC* pDC, CPrintInfo* pInfo)
{
if (pDC->IsPrinting ())
{ DEVMODE* devMode = pInfo->m_pPD->GetDevMode ();
devMode->dmOrientation = DMORIENT_PORTRAIT;
devMode->dmFields |= DM_ORIENTATION;
pDC->ResetDC (devMode);
}
CScrollView::OnPrepareDC(pDC, pInfo);
}
Can someone explain me where the two codes differ and which one is better from the aspect of printing compatibility in different printers? 
And the only problem I can't solve is:
By placing the bitmaps of the elements in my program (is a simulator) I used
void CMyView::OnPrint(CDC* pDC, CPrintInfo* pInfo)
{
pDC->SetMapMode (MM_LOMETRIC);
CDC dcNormMem;
dcNormMem.CreateCompatibleDC (pDC);
BITMAP bmNormTemp;
CBitmap bmNormIn;
bmNormIn.CreateCompatibleBitmap (pDC, 2 * SIGWIDTH, 2 * SIGHEIGHT);
if (pInfo->m_nCurPage == 1)
{
if (bmNormIn.m_hObject != NULL)
bmNormIn.DeleteObject();
bmNormIn.LoadBitmap (IDB_NORMIN);
bmNormIn.GetObject(sizeof(bmNormTemp), &bmNormTemp);
dcNormMem.SelectObject(&bmNormIn);
for (int nIn = 0; nIn < nTotalIn; nIn++)
{ pDC->StretchBlt (
2 * pDoc->m_cmlInputSet[nIn].m_cpInCoord.x,
-50 + (-2 * pDoc->m_cmlInputSet[nIn].m_cpInCoord.y),
2 * bmNormTemp.bmWidth,
-2 * bmNormTemp.bmHeight,
&dcNormMem,
0,
0,
bmNormTemp.bmWidth,
bmNormTemp.bmHeight,
SRCCOPY
);
}
}
}
It was working perfectly in three different printers here in the Firm (one Brother HL-2040 series, one HP DeskJet 930C/932C/935C and one ploter HP Designjet 70). But from one day to the next, the bitmaps didn't come anymore   . It is just drawn a point in the corner (top-left) of the bitmap, and nothing more. Text, lines, self-drawn graphics and so on work good.
I suppose it has something to do with DDB and DIB bitmaps, and now I'm creating the function to transform it but...  Why the hell it was working good during days and suddenly worked no more?  And the thing is pissing me off is that I have tried with the backups of the versions that were working right, but they can not print the Bitmaps as they actually did during days...
Can someone tell me the reason? I will try with the conversion in DIB and the StrechDIBBits but I would like to know what happened.
Thanks.
Sorry for the large of the message and if I have failures (I'm not english speaker)
EDIT: In Bold
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
i am trying to port my App from 32 bit to 64 bit. so installed VS2005 on my 64 bit OS and did some setting in configuration manager, i.e x64 and did some project setting Project->Properties->Configuration Properties->General->Common Language runtime support->No Common Language Runtime support.
so it is giving a error
kernel32.lib(KERNEL32.dll) : fatal error LNK1112: module machine type 'IA64' conflicts with target machine type 'x64'
With Regards
RYK
|
|
|
|
|
Check your project settings under 'Configuration Properties / Linker' and check the target machine type is set to 'MachineX64' this will tell the compiler to build for a x64 processor, at the moment it looks like it's set to IA64 (Itanium)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
