|
|
FindFirstFileEX(), SearchPath() APIs will be handy.
Armond Sarkisian wrote: Once I find the certain file I want to compare it with a flat file database of known MD5's.
this is like a project proposal
modified on Saturday, February 16, 2008 4:01 AM
|
|
|
|
|
Rajkumar R wrote: this is like a project proposal.
It's urgent too.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
|
dear all
i would like to compare two values magnitude, and first time i initialize one of them is 0,when second one was generated from code, i will sign second value to first one, and then in next iteration, second value will be get again from code, i want to subtract first one from second, and if the subtraction is less than certain value, then stop iteration. the example is below: but however i couldn't solove it.
sumOnePre = 0;
sumOne = sumOne + g(j);//this is already calculated in my code
if sumOne ~=sumOnePre
sumOnePre = sumOne
if sumOne - sumOnePre < 0.015
ct1 = km;// they are calculated already
but here, the problem is after sumOne is calculated currently,doesnot use first if statement, instead taking second if statement, and then use first if statement, however i couldn't solve it. anyone help me? thanks a lot
Li Zhiyuan
|
|
|
|
|
li zhiyuan wrote: if sumOne ~=sumOnePre
means?
|
|
|
|
|
actually sumOne is great than or equal sumOnePre
Li Zhiyuan
|
|
|
|
|
i didn't get u exactly,
li zhiyuan wrote: if sumOne >=sumOnePre
sumOnePre = sumOne
if sumOne - sumOnePre < 0.015
ct1 = km;// they are calculated already
if ur first if statement succeeds, then second if statement never evaluates to true. if this is ur problem,
SumOne = Calculate();
if (Sumone > SumOnePre)
{
if (sumone - somOnePre < 0.015)
{
}
someOnePre = somOne;
}
else
{
}
li zhiyuan wrote: doesnot use first if statement, instead taking second if statement
this can happen when sumOne < SumOnePre, if u r expecting Sumone >= SumOnePre, then if g(j) is correct i think intialisation problem,
li zhiyuan wrote: sumOne = sumOne + g(j);//this is already calculated in my code
does sumOne is initialised?
ur question is not clear.
|
|
|
|
|
I maintain a robust and stable MFC based app using VC++7.1 (VS2k3).
I'd like to bring that app's UI into this century and I think that integrating WPF may be a good way to do it. I installed VS2k8, and tested some samples that used WPF controls within a MFC container. Good.
My next step was to do some simple tests to see how I could use .NET with my app. Using VS2k8, I created a simple c# class library. Then I used regasm to create a .tlb. Then I built a simple test client in C++ and instantiated the .NET object through a COM wrapper. Still good.
Now I fire up VS2k3 and build the same test client using VC7.1. No luck! When I try to instantiate the COM object, it throws a class not registered exception.
What's the difference? As far as I can tell, the VS2k3 app is loading up the .NET 1.1 DLLs and the VS2k8 app is loading up the .NET 2.0 DLLs.
My app uses some 3rd party class libraries that don't build well on VS2k8 yet so I'm stuck using VS2k3. Is VS2k3 going to let me use the WPF controls that I build using VS2k8?
|
|
|
|
|
Simple solution... No need to compile with the /clr option in this case. COM is COM. You don't need to worry about managed extensions in this case. Just use the COM object like any other COM object.
Now, when the COM object is instantiated, the .NET 2.0 dlls are loaded and everything works correctly.
|
|
|
|
|
I know this is not a place to put an ActiveX question. But i couldn't find another group to post this question.
I am using the MS Mask Edit control in my program and for that i have included the following files in project.
1. msmask.cpp
2. msmask.h
Now i try to do a CoCreateInstance passing the Class ID of msmask as the 1st parameter.
I get an error saying the "Class is not registered".
I am not using the msmask32.ocx in my project or have it in any folder. But if i get a msmask32.ocx and register it using the regsvr32 command, the CoCreateInstance function works fine.
My question is, can i work with msmask cpp and h file without having to register the msmask32.ocx file?
Any help is welcome.
|
|
|
|
|
You can't use an OCX without registering it.
|
|
|
|
|
I'm learning how to build DLLs, and I've had some observations, and I was wondering if someone could provide me some insight. In Visual Studio 2005:
1) Created a new project
2) Using the project wizard created a MFC regular DLL using shared MFC DLL. (no other options selected)
3) Added a method to the default class generated by the wizard called "Execute"
void Execute();
4) Defined the method
void CTestApp::Execute()
{
return;
}
Added the method for export in the module definition file (.def)
LIBRARY "Test"
EXPORTS
Execute
When I compile I get a link warnings/error:
1>Test.def : warning LNK4022: cannot find unique match for symbol 'Execute'
1>Test.def : warning LNK4002: "public: void __thiscall CTestApp::Execute(void)" (?Execute@CTestApp@@QAEXXZ) defined in .\debug\Test.obj
1>Test.def : warning LNK4002: "public: void __thiscall CDaoDatabase::Execute(unsigned short const *,int)" (?Execute@CDaoDatabase@@QAEXPBGH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : warning LNK4002: "public: void __thiscall CDaoDatabase::Execute(wchar_t const *,int)" (?Execute@CDaoDatabase@@QAEXPB_WH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : warning LNK4002: "public: virtual void __thiscall CDaoQueryDef::Execute(int)" (?Execute@CDaoQueryDef@@UAEXH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : error LNK2001: unresolved external symbol Execute
1>C:\Documents and Settings\fi507c\My Documents\Visual Studio 2005\Projects\Test\Debug\Test.lib : fatal error LNK1120: 1 unresolved externals
So I've come across two solutions
Solution 1: Instead of using a .def file, use __declspec(dllexport) to export.
This solution makes sense, since it automatically creates the .def file for me. But I'm not sure what the issue with the .def file was. Was it due to name decoration?
Solution 2: Instead of calling my method Execute, call it something different, like Axecute.
This is somewhat odd to me, just by renaming the method to something else, the .def file works to export the function. Does it have to do with the some of the linker warning/error information? Wouldn't name decoration still cause an issue?
|
|
|
|
|
You'd need to fully qualify the name in the def file (like "CTestApp::Execute")
because no Execute function exists in your project.
That will get rid of all the warnings but then the name mangling will still prevent the link.
Using __declspec(dllexport) is recommended over using the EXPORTS section of the def file.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
HA did I get hooked! I'm flopping around all over this boat[^]
led mike
|
|
|
|
|
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
*snicker* 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
I am working on a small game engine which is designed to work on multiple platforms when recompiled. At the moment I am targetting win32 and linux. Using Win32 with Visual C++ it is easily possible to create DLLs which export classes, objects, and functions. However I have some problems for which I would be really greatful if you guys advise me with.
The first problem is compatability with compilers:
I am told that DLL's compiled with Microsoft Visual C++ (without MFC) will not be compatible with other compilers such as Borland because of a technique called name decoration (or name mangling).
The second problem is compatability with platforms:
This is the first time I have attempted dynamic linking with linux/unix. I am fairly confident with dynamically accessing exported functions...but as far as classes and objects are conserned I think I am going to have a lot of problems with dynamic linking.
I have been searching extensively on the net, and I am gradually drowning in confusion  . The only solutions I can find are pretty extreme:
- Convert all of my C++ libraries to ANSI C libraries. (defies some of my design objectives and generally not a good solution, but on the bright side some things would execute more efficiently)
- Find another low-level OOP language which does meet my needs. (makes my target audience smaller)
- Extend my scripting engine into a full-blown language by translating into assembly code and then assembling using a third-party assembler such as FASC. (a very big and complex task which i would rather avoid, but would stoop to if absolutely 100% necessary).
The ideal solution for me would be a standard name mangling convention (without the use of an interface which would seriously damage performance) which works across a wide range of platforms including win32 and linux/unix.
I look forward to hearing your ideas. 
Lea Hayes
|
|
|
|
|
I've run into everything you're experiencing. Fun stuff....not!
lhayes00 wrote: I am told that DLL's compiled with Microsoft Visual C++ (without MFC) will not be compatible with other compilers such as Borland because of a technique called name decoration (or name mangling).
Absolutely correct. To use you C++ DLL, you need to match compiler vendor (and probably version as well), in addition to having the same linkage model (i.e. whether or not you're linking the CRT statically or dynamically). Alternately you can use COM and completely get around this.
You will not be able to use a binary object (i.e. a dll/shared obj, etc) compiled on one platform on another. In other words, you can't use a DLL compiled on Windows and hope to link to it dynamically on linux. For a whole bunch of reasons.
Like I said one option is COM. Alternately the Mozilla project produces XPCOM which works on linux/Win32/OSX, etc. However you still can't share the binaries between platforms (if that's something you're hoping to do).
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
I have just looked up XPCOM on the Mozilla website and it looks quite promising! My next task is definately to read through the PDF book provided on the XPCOM website.
Thank you very much! 
Lea Hayes
|
|
|
|
|
As ur requirement is simple and just require to export a Class from DLL, i think the complete COM framework is not needed, use the basic stuff, export single c funtion to create an instance of class,
CYourDLLClass *pObjOfDllClass = NULL;
CreateDLLClassInstance((void **)&pObjOfDllClass); //exported C function.
then use pObjOfDllClass as normal Class object.
|
|
|
|
|
Hi,
If an object of a class is created from an exported function, surely all functionality would need to be exported using C style functions (where the object pointer is treated as a handle). If exported classes are used, DLL's compiled with a different brand/version of C++ compiler will be unable to import class members due to the problems with name mangling.
Appologies if I have missunderstood what you have said.
Thanks for your reply,
Lea Hayes
|
|
|
|
|
i meant u don't need to export class, only one C function to create an instance of the class object, COM does this. COM uses DLLGetClassObject to create an instance of the factory method interfaces.
say,
BOOL CreateDLLClassInstance(void **ppClassObj); // exported C function to create an instance note type is void ** and no class declaration is visibly exported.
lhayes00 wrote: If an object of a class is created from an exported function, surely all functionality would need to be exported using C style functions
this exported function is not part of the class, the function is outside the namespace of the class.
lhayes00 wrote: where the object pointer is treated as a handle
just typecast the HANDLE to your object class type.
|
|
|
|
|
Ahh rite now I see what you mean!
Thank you for clarifying, I am sure that I can put this to use
Lea Hayes
|
|
|
|
|
Depending on the design of your library, a good solution would be to make C entry points into it, using a technigue called "flattening[^]", thus exposing the C interface while keeping the C++ internal implementation.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
