Which variables ?? What are you talking about ? Try to be more explicit because otherwise we won't be able to help you. One thing: I think that your problem has probably nothing to do with the fact that this is a dll (it's just a guess) so don't focus on that problem only.
Like others, I have no idea what you are asking, however, I think what Chris was trying to get at is that you must be careful how you allocate and deallocate memory between DLL/EXEs.
If your software is using CRTL linked statically, then the EXE and DLL will be using different heaps. Thus if you allocate memory in a DLL and return a pointer to that memory to your EXE, you must then invoke a routine in the DLL to free the memory. Otherwise the EXE will try to free that memory back to its heap that doesn't know about the memory. There are other ways to avoid this such as using the process heap or CoTaskAlloc from OLE/COM. That gets around the problem by using a process wide, well know allocation system that everyone in the process has access to.
Another common problem is improperly declared function prototypes. For example, if your EXE defines your routine as using C++ calling convention but it is really using __stdcall, then bad things will happen. The stack won't be properly managed and variables will appear not to be assigned properly back in your EXE.
I'm going to patent thought. I have yet to see any prior art.
Yes, there is! I've done this on a regular dialog, I don't have much experience with property pages, but I think it will work.
Change the id of the dialog that you use for your property page to IDD_FILEOPEN_EX.
Delete the OK and Cancel buttons.
Select 'Clip Siblings' and 'Clip Children' in the dialog's properties.
Create a static control and change it's id to "stc32" (no quotes).
In your Resource.h file, delete the definition for stc32.
"stc32 is a constant #defined in dlgs.h, so #include dlgs.h in your .rc file.
the file dialog should now show up in place of the static control on that dialog.
I have a .lib file which has all the necessary functions which are written in ANSI C. I wanted to use these functions in C#. So I decided to include and use them in a class library file which is to be written in C++ (VS.NET-Class library proj., right? ), then import this class library to my real C# project. So,I have inluded all the include files, library file to my project. But when I try to compile it I end up with the error:
""error LNK2019: unresolved external symbol _main referenced in function _mainCRTStartup""
my .h file:
public __gc class uFWrapperClass
I have also tried it. But it did not worked for me I think the problem is releated to the .lib file I am trying to use. It seems to be compiled with VS6. In VS6 we could import .lib files to the project from the "Add File..." menu. Is there some way to import .lib files in VS.NET to the VC++ projects? As I have read there is noway to import .lib files to C# projs. (Correct, right?)And thanks for your suggestion by the way.
I am a VC user, now I use VC6.0, but this many a day , I am troubled by the Visual C++ 6.0 IDE's BOOKMARK question.
As you know ,you can use short cut key <Alt> + F2 to add a bookmark to your project, or you can use short cut key <Ctrl> + F2 to add a color marked bookmark to your project. I am used to the first method to add a bookmark to my VC project.
But long ago , I have sadly found that I couldn't add any bookmark to my project! I use short cut key<Alt> + F2 to activate the "bookmark" dialog, I input the name of my bookmark, such as MyBookMark, and then I click "Add" button to add a new bookmark to my project ,but unfortunately, the below bookmark list has no reflection, i.e, my newly added bookmark can't be seen in the bookmark lists now! however I do, I only find that I can't add any new bookmark to my project!!!
Why this happened ??? I am eager to know the reason and how to solve the troublesome problem.
A known issue ? I want to know whether some progress has been made for this subject in VS.NET 2003
or later version of VS ? Is there really no better way to solve this bug ? In the days when computer technology has been upgrated rapidally, I think such technique question is out of question for so famous company ---MICROSOFT , but why Microsoft hasn't correct this troublesome bug??? puzzling...
I'm converting a project originally written in VC++ 5.0 using MFC. This framework tends to use the uppercase BOOL, TRUE and FALSE for boolean type. The later frameworks include the lowercase bool, true and false as the boolean type. You can't use them together or you will face compiler warnings about performance drop due to converting.
So the question is simple: What to use?
Whats the difference?
Wich is better, and on what field?
small 'bool', its a primitive data type like int,char..etc and accepts only 0 and 1 ... anything above 1 say..2,3,4 taken as 1 only.
BOOL is basically of int type so accepts any values other than 0 and 1..
i think its better to use bool.
hey this is my finding!!.. wait for better responses..
bool is a type builtin C++ (standarized) and BOOL is defined by Microsoft and it's an int (defined in 'windef.h'). An important difference is their size: if you perform a "sizeof" for a bool, it's 1, and in a win32 platform a BOOL has 4 bytes.
BadKarma wrote: So the question is simple: What to use?
Depends on what you need, if you need something more portable or just a binary variable I'd choose bool if you need a wide range of values then BOOL.
BadKarma wrote: Wich is better, and on what field?
I prefer bool because it's a c++ standard and when I need a wide range of values I use an int.
... she said you are the perfect stranger she said baby let's keep it like this... Tunnel of Love, Dire Straits.
In theory yes, but in practice no. Anytime you are using a non-Boolean to represent a Boolean value, you have to be careful how you test for TRUE or FALSE. For example "if (x == TRUE)" is a VERY bad idea since it yields different results than "if (x)".
Now using this information that a BOOL can have four billion different values and returning more results than just TRUE(!=0) or FALSE(==0) is a bad bad thing. (Which is the case I am sure you are referencing.)
I'm going to patent thought. I have yet to see any prior art.