|
vivekphlp wrote: ometimes The Intellisense of my VC++ Editor disappears- I am using Microsoft's Visual Studio 6.0
So when i try to put a . the popdown menu is not displayed .. .
Any solutions????
close down your project and remove .ncba nd .clw file and reopen the project to see Intellisense working again!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
hi guys, i need to move a dialog to another project of the same solution in Resource View. after that still build successfully but when i click to start the dialog, it doesn't appear, any idea?
thanks!
|
|
|
|
|
nathan7 wrote: move a dialog into another project in the same solution?
Did you try to debug your application?
What happens if the dialog doesn't show up?
Does your application hang or something else?
How do you create your dialog and show it?
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: Did you try to debug your application?
What happens if the dialog doesn't show up?
Does your application hang or something else?
How do you create your dialog and show it?
i'm using debug configuration, if this is what u meant?
nothing happened, i click ok in the parent dialog, and nothing happened
use create() to create, modaless dialog
|
|
|
|
|
I was not asking about what configuration are you using for your build. Do you put a breakpoint in your code and step into the debugger to see what is actually happening behind your code?
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
