|
you defined a variable called "exception" on line 759 of project.cpp. You never bothered using it.
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
I would like to write a function in C++ and compile that into a .dll that I can access within Visual Basic. The purpose behind this is a company restriction and I feel the process can be handled most efficiently in the C++ environment. Does anyone know what I would need to do to compile it as such.
Here would be an example, but not my particular function:
int SumValue(int a, int b)
{
return a + b;
}
Thanks in advance
Nick Parker
|
|
|
|
|
COM is really the only way you can do this. I'm not much of a VB expert, but to get a function pointer in a DLL requires pointer support, which VB doesn't have. Therefore, you're going to need to create a C++ COM object with a method called SumValue. You should then be able to use this in VB.
You should be able to find plenty of articles about how to create a simple COM object on this site.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
I've created what I believe should be the method to do this:
1. Created a Win32 Dynamic Linked Library
a. Choose a simple .dll project
2. Wrote the function inside the header file.
3. Compiled the .dll ok and exited VC++
Launched VB
1. Added a module
2. Included the following code for the module
Declare Function SumValue Lib "sum.dll" (ByVal a As Integer) As Integer
3. Put a button on a form where I try to call the function SumValue
4. Get an error:
Run-time error '453' Can't find DLL entry point SumValue in sum.dll
Does anyone have a clue?
Thanks again
Nick Parker
|
|
|
|
|
I believe VB supports __stdcall functions from DLLs (like nearly the entire Win32 API). Try adding these lines to your function :
__declspec(dllexport) __stdcall int SumValue(int a, int b)
For my code I have a DllExport macro. If I were you I would probably make a macro to handle all of the above.
My jokes page
|
|
|
|
|
The function that you just wrote should be written like this to export it from the DLL.
__declspec(dllexport) __stdcall int SumValue(int a, int b)
{
return a + b;
}
dllexport exports it from your dll, and __stdcall is the calling convention that VB accepts. _cdecl is the default calling convention therefore if you just simply exported your function from the DLL and used it in VB, you program would probably crash.
In you VB program, at the top of the file that you would like to call this DLL, you will need to make this declaration.
Declare Function SumValue& Lib "yourdll" (ByVal a as Integer, ByVal b as Integer)
After this you should be able to use your function in VB.
|
|
|
|
|
Some articles and samples on writing DLLs in C++ for use with VB by Bruce McKinney:
http://www.vb-zone.com/upload/free/features/vbpj/1999/mckinney/CppForVB.zip
(sorry, its a ZIP, i cant seem to find the HTML online)
--
David Wengier
|
|
|
|
|
ostream& operator << (ostream& s, Stocks& stocks)
{
for(int i = 0; i <stocks.numofstocks; i++)
="" {
="" s="" <<"stock="" information:="" "<<="" (stocks.mystocks[i]).getcompanyname()<<"="" "<<stocks.mystocks[i].getstockticker()<<"="" "<<stocks.mystocks[i].getmarkettraded()<<"="" "<<stocks.mystocks[i].gettypeofmanufactr()<<"="" "<<stocks.mystocks[i].getinitialvalue()<<"="" "<<stocks.mystocks[i].getnumofoutshares()<<endl;
="" return="" s;
="" }
}
i="" really="" should="" not="" use="" any="" other="" classes="" but="" the="" <string.h=""> and <iostream.h>
in my project, so if you can tell me how to get this method to work, i know that my return statement should not be inside the body loop
but how do i fix it?
by the way this method is in a class called Stocks that holds an array of the class objects Stock. and the class Stock defines this method as well but ithout any loop.
our teacher was saying that when we try to use this method in Stocks class it will automatically call the same ostream method in class Stock
can any one tell me how is that?
|
|
|
|
|
no other classes can be used in this project!
thank you
|
|
|
|
|
:\Windows\Desktop\Project2\Project.cpp(253) : warning C4715: 'operator<<' : not all control paths return a value
C:\Windows\Desktop\Project2\Project.cpp(387) : warning C4715: 'operator<<' : not all control paths return a value
here are the warnings it was giving me.
|
|
|
|
|
Firstly, if you are using the < character in your message, you should check the "Display this message as-is" box so that the HTML doesn't get mangled.
Marwan wrote:
our teacher was saying that when we try to use this method in Stocks class it will automatically call the same ostream method in class Stock
can any one tell me how is that?
OK, I think what your teacher is saying is that if you have two classes:
class Stock
{
...
ostream& operator << (ostream& s, Stock& stock);
};
class Stocks
{
ostream& operator << (ostream& s, Stocks& stocks)
Stock *m_aStocks;
}
then in the << operator of the Stocks class, you don't need to output all the individual members of each Stock object. Rather, the Stocks class should go through all the Stock objects, and call the << operator on the Stock class. Then, the << operator on the individual Stock class should output all the elements of Stock.
What this means is that the loop in the code you quoted shouldn't have a return statement inside it. You need to return once the loop is finished. Also, the << operator for Stocks shouldn't be << each element of each Stock.
Hope this helps.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
Your teacher wants you to read two topics:
(1) operator overloading
(2) polymorphism
Although I personally can give you a complete answer to your question (as I have given similar question to my students) but I believe that if you simply read the above mentioned topics you would be able to solve the problem yourself.
Basically the "Stock" object has an implementation of "<<" operator that outputs the conctenated string containing the attributes of Stock object
The "Stocks" object will have its own "<<" which uses the "<<" of Stock to produce a consolidated string that shows the details of ALL the stocks.
You have already noticed that the return from with in the loop will give you an error. Since you for () condition is not properly shown (due to HTML format) i can't really see why u are returning from with in the loop - because this way your loop will only run once (but i guess u already know this).
-cheers,
kashif manzoor
peace to all
|
|
|
|
|
Hi 
If someone knows how to deal with the following problem, please help me![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif) :
I need to install a callback between 2 applications and I would like to install that callback through a dll. (please don't tell me to use messages between my two applications: I really need application1 to call and work in a function in application2. Application1 & application2 don't know each other, they just know the dll).
How do I have to declare thing in application1, application2 and in the dll
Thanks
|
|
|
|
|
Okay, I have done this sort of thing in VB, so maybe this will help, or maybe I am on the completly wrong track.
Application1 knows about a DLL which contains an interface.
Application2 has a class that supports the interface.
On install, application2 puts something in the registry that says "I am a valid thing for you to talk to. Here is my ProgID"
On run, Application1 check the registry, finds all of the "things it can talk to", and uses them, by calling methods, properties etc. of the interface.
Is that what you are looking for or is it completly wrong?
--
David Wengier
|
|
|
|
|
Thanks, but my problem is much more "how to write the code":
I don't need the registry because each application registers itself inside of the dll everytime they are launched. I just want to know how my interfaces have to look like, eg:
********** Application2 ******************
installTheCallback(callbackAddress);
...
LResult callback callbackAddress(???)
{
...
}
********** DLL **************
BOOL declspec(dllexport) __stdcall installTheCallback(???)
{
???
}
BOOL declspec(dllexport) __stdcall jumpToTheCallbackRoutine()
{
???
}
************** Application1 ******************
jumpToTheCallbackRoutine();
Basicaly I don't know what is needed where I put "???"
|
|
|
|
|
Hello Mr Freeze,
From the description of your question, it seems you need one of the following options :
1. RPC (Remote Procedure Call)
2. COM (Component Object Model)
RPC seems the most appropriate option for you. The COM option will be largely based on RPC also. These two options will have no need for any middle DLL between your two apps.
I also need to explain carefully that it is generally NOT POSSIBLE to have one app call a CALLBACK function on another app. This is so even if the callback function resides in a DLL. The reason is that the two apps are in two different address spaces.
RPC seems the best choice for you, Mr Freeze. I'll try to search for a sample for you.
Best Regards,
Bio.
|
|
|
|
|
Thanks for your reply
When I install a callback with "glutDisplayFunc(functionAddress)" (it's a function which installs a callback to render a scene in OpenGL), is that function also using RPC??
|
|
|
|
|
Hello Mr Freeze,
I haven't used OpenGL before. I'm not familiar with it. But I believe that to use it, you would link with OpenGL DLLs. The function you mentioned, glutDisplayFunc(), is probably exported from one of the OpenGL DLLs.
Assuming that this is the case, the OpenGL DLLs are in the same address space as your app. No RPC is required in this case. The OpenGL functions (like glutDisplayFunc()) is free to call your functions (callback or otherwise) directly.
This same principle is used with several Win32 APIs like EnumWindows() which takes a pointer to an EnumWindowsProc(). This EnumWindowsProc() must reside in your application. The EnumWindows() function is in USER32.DLL which is loaded into the same address space as your app.
Let me know if you need further clarifications, Mr Freeze.
Best Regards,
Bio.
|
|
|
|
|
Thanks again Bio
I am quite new to all this and might be a bit slow understanding... but a last question:
The dll linking my two applications has a shared data segment. Does this simplify something?
What about just overriding an unused window function in application2 and then, in application1 calling : FromHandle(app2WindowHandle)->the_overrided_function() ??
Best regards
|
|
|
|
|
Hello Mr Freeze,
You're most welcome, Mr Freeze. Joaquin has supplied a possible solution to your problem with the use of Shared Data Segments (please read his message to you in this thread).
I have tried it myself but there are some issues with it (please refer to my response to Joaquin's message).
>> What about just overriding an unused window function in application2
>> and then, in application1 calling :
>> FromHandle(app2WindowHandle)->the_overrided_function() ??
I'm not 100% sure about this, Mr Freeze, but I doubt if it will accomplish what you are setting out to achieve. Let's see what Joaquin says about my concerns over the Shared Data Section.
Regards,
Bio.
|
|
|
|
|
Hello Bio,
Thanks a lot for your clarification and your precious help
Best regards,
Marc
|
|
|
|
|
Hello Mr Freeze,
You're most welcome, Mr Mreeze. I'm searching for a suitable RPC sample and will email you if I manage to find one.
Best Regards,
Bio.
|
|
|
|
|
In one of your posts following this, you said you've declared a shared data segment. Keep it, you will need it for what you're after.
The trick is having a function pointer storing the callback in the shared data segment:
typedef BOOL (WINAPI * MY_DLL_CALLBACK)(int);
#pragma data_seg(".MYSEC")
MY_DLL_CALLBACK pMyDLLCallback=0;
#pragma dara_seg()Now you just export functions setting and using this pointer:
extern "C" __declspec(dllexport) void setCallback(MY_DLL_CALLBACK *pCallback)
{
pMyDLLCallback=pCallback;
}
extern "C" __declspec(dllexport) BOOL callCallback(int parm1)
{
return pMyDLLCallback(parm1);
}Having the pointer declared in a shared data segment is required so that both apps "see" the same variable (by default, EXEs have their own copy of all the data in DLLs, regardless of whether the DLLs are being used by other apps).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hello Joaquin,
Your suggestion is very good, Joaquin. Yes, the use of a Shared Data Section seems quite useful and may have great potential for Mr Freeze's problem. I tried using Shared Data Section with the following architecture :
1. App1 links with Shared DLL and calls setCallback(<pointer to CallBack Func() in App1>).
1.1 This sets "pMyDLLCallback" to the address of Callback Func in App1.
2. App2 links with Shared DLL and calls callCallback(<some value>).
2.1 This makes callCallback() call a function whose address is stored in "pMyDLLCallback".
There is a problem in 2.1 because the address in "pMyDLLCallback" points to is in the address space of App2. And App2 does not contain the Callback function in App1.
In this case, App2 will either crash or may execute some function which is not the same Callback function as that in App1. It may even dive straight into the middle of some function in itself.
Is my analysis correct, Joaquin ? Please let me know as I may have totally misunderstood your solution.
Many Thanks,
Bio.
|
|
|
|
|
Hello Lim,
I'm afraid your analysis is 100% correct. Conclusion: my approach is useless. Didn't think about the address space issue. As you pointed out, one cannot execute a function belonging in a different module.
So, seems like viable solutions involve some kind of interprocess marshalling --hand-made sockets or Windows messages stuff, COM and RPC are the candidate technologies that come to my mind.
Thanks for pointing out the flaw in my (so-called) solution.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
