|
#import is a compile-time thing, not runtime. Use the path to the file on your machine.
--Mike--
Just released - RightClick-Encrypt v1.4 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I wont know where the user will install the app, so the dll cant be put in the app folder on the target machine. Thats why I'm wondering if I should install it in their system folder (since my com dll is not an ADO dll though it is database related...):
#import "c:\Program Files\Common Files\system\ado\msadox.dll" no_namespace
#import "c:\Program Files\Common Files\system\myVBCOM.dll" no_namespace
I have control over where WISE installs the dll, but the user can choose his own directory for the app, so thats an unknown.
|
|
|
|
|
#import is compile-time. All that matters is where the DLL is on your machine. When your app creates the COM objects, the location of the DLLs doesn't matter because COM looks in the registry to get the file paths.
--Mike--
Just released - RightClick-Encrypt v1.4 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Mike,
Could you rephrase that one last time please
jon
STL is a religeon. Enquiries to Reverend Christian Graus
|
|
|
|
|
Hello,
When I am declaring CSocket in VC++, what .lib should I include in the link?
Thanks!
Nachi
|
|
|
|
|
Normally, only MFC libraries will suffice. If you're developing your own CSocket, you can #pragma comment(lib, "ws2_32.lib")
Concussus surgo.
When struck I rise.
|
|
|
|
|
|
For that matter I dont know how one can debug a VC dll called from VC. But at the moment I have a VB dll that I'm calling from VC. I'm putting msgboxes in the dll and rebuilding each time, but its really inefficient. How to do this the right way?
Thanks,
ns
|
|
|
|
|
We don't really understand where your orblem lies, or did you mean to reply to someone?
With time we live, with money we spend!
Joel Holdsworth.
|
|
|
|
|
Sorry I was terse. I need to know how one can "step into" the code of a VB dll called from VC to see whats wrong. Is this even possible?
(Can this be done if VC is calling a VC dll? ). I am suspecting that the private declares in my VB dLL may need to be changed to public but I dont know VB so I am off to investigate. Hope I'm clearer this time 
|
|
|
|
|
Hi Again,
In my memory, isn't visual basic separte from the dev studio ide? consequently if you do try and step into a VC dll, you'll be confronted with assembly instructions. So you may be up the creak there. Unless you can convince VB to make your VC program the executing program for your dll. So you ask VB to run the DLL by running the C++ program, in which case you can make it halt just at the beginning of the appropriate function. Failing that I think you are reduced to making your dll flash up MessageBoxes to trace out the problem! Sorry I don't know anything more useful...
With time we live, with money we spend!
Joel Holdsworth.
|
|
|
|
|
THe VC app is calling the VB dll. Thanks for your input anyways. I'm putting in messageBoxes....
|
|
|
|
|
Joel Holdsworth wrote:
In my memory, isn't visual basic separte from the dev studio ide?
It is, but the VC debugger as capable og debugging both C++, VB and Java.
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
On Visual Basic, on "Project Properties" Dialog, Select "Compile" tab, check "Compile to Native code", "No optimization", "Create Symbolic Debug Info"
Concussus surgo.
When struck I rise.
|
|
|
|
|
I have only done it with COM Objects written in VB and used from VC.
You go into your VB project settings and tell the compiler to generate debug info (.dbg-files I think), and you have to turn optimation off.
Then you place the .dbg-files and your dll in the same place, and from the VC debugger you just step into the code. The first time you do that, it asks for the VB source. Works perfectly fine, I have done it a couple of times with COM Objects written in VB...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
OKay then,
heres another question, Debug a VB application that is calling code from a VC++ DLL...
Ryan Baillargeon
Software Specialist
Fuel Cell Technologies Inc.
|
|
|
|
|
Have never tried, but I guess it should be possible to debug a VB .exe from VC...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Appreciate it. Am trying it out now,
thanks,
ns
|
|
|
|
|
Hi Everyone,
The clue's in the title of this post! Does anyone know of a free open source windows C++ compiler and that will interface with MSVC compiled dlls? I know its a tall order, but I was hoping you guys would rise to the challenge. The reason is that I'm making a totally flexible image making program, which is composed of user coded units, which are compiled at runtime, so it will allow users to do graphics programming simply like they did in the dos days, but with a whole lot more power to play with! The system works really well using the MS compiler, problem is that MS will not be impressed if I distribute copies of this program with their compielr included, so does anyone know of an alternative? Thanks for your time....
With time we live, with money we spend!
Joel Holdsworth.
|
|
|
|
|
Hi
Thanks for your a lot input. I'm very impressed by that compiler of yours. It could well become part of my program! It is quite important that the compiler can deal with C++, because I exploit the object orientation and inheriatance heavily, so its not just a case of finding a C compatible compiler...
With time we live, with money we spend!
Joel Holdsworth.
|
|
|
|
|
I'm not sure if you have seen G++, but here is a link to it:
http://www.gnu.org/directory/devel/compilers/gpp.html
Sorry if the GPL licensing is not ok (I'm not sure).
Chris Richardson
|
|
|
|
|
Hello,
Is anyone know that if in the network, computer A keep sending message to computer B but computer B does not execute the recv() routine. What will actually happen? If the answer is buffer overflow, then, is it mean the later message will overwrite the earlier message?
Nachi
|
|
|
|
|
Nothing will happen, the computer a will fail to connect
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Realistically what ultimately occurs if one systems continues sendng packets to another system is a network overflow. In otherwise, the sending system floods the networking connection of the receiving system. In an non-blocking I/O model, the receiving system will continue getting incoming messages.
Kuphryn
|
|
|
|
|
Using #import statement (calling a VB dll from VC)
I have a database app which uses CoInitialize (MFC MDI). Now i want to add another menu item which also will be calling CoInitialize but for a different com library. Is there any danger here with multiple CoInitialize? Also, in my main prj at one place I had (at one time) two #imports but only one CoInitialize. MSDN is cryptic and I;m not too clear about it. At some time I recall someone cautioning against multiple CoInitialize...
Thanks,
ns
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
