- Forum
- Windows Programming
- Include C++ & VB In Same VC++ App???
Include C++ & VB In Same VC++ App???
Is it possible to include VB in a C++ project/solution in Visual Studio?
I know I can include Assembly, as I've done very short stuff with inline Assembly, but what about VB?
I know I can include Assembly, as I've done very short stuff with inline Assembly, but what about VB?
You can certainly CALL VB scripts from a C++ app, but what exactly are you trying to do?
I'm just thinking about using VB to connect to ODBC, but I've decided against it. I'm staying with straight C/C++ Win32 API.
I would love to have your knowledge of computer architechture and general knowledg of computers, so I am going slowly through an Assembly Language book, but I spend very little time on it, as I got so many things to learn right now that I need to just pick one and stay with it.
FRED I got your email, but I can't send it back, probably because I've enclosed a ZIP file, and your email came through this server.
Just go to my website and click on the "Contact" button and email me directly, then I will send you back what I've already tried to send you. Here is my website --
http://www.lamblion.net
I would love to have your knowledge of computer architechture and general knowledg of computers, so I am going slowly through an Assembly Language book, but I spend very little time on it, as I got so many things to learn right now that I need to just pick one and stay with it.
FRED I got your email, but I can't send it back, probably because I've enclosed a ZIP file, and your email came through this server.
Just go to my website and click on the "Contact" button and email me directly, then I will send you back what I've already tried to send you. Here is my website --
http://www.lamblion.net
Last edited on
To clarify the doubt, you can only interface with classic VB from C++ via COM interfaces, and the same is true if the C++ is unmanaged and the VB is VB.net.
If you use C++/CLI, however, you can use a .Net assembly written in VB.net or C# or whatever without much restriction.
If you use C++/CLI, however, you can use a .Net assembly written in VB.net or C# or whatever without much restriction.
Thanks for the clarification. It looks like I'm eventually going to be forced into some C# code whether I like it or not.
COM is a PITA, but trust me it's worth the effort. Alternativley something I used to do is write VB Scripts with fstream, this may or may not work for you but I thought it was worth mentioning.
I think I'll keep it simple and just do everything from a straight C/C++ front end, no matter how much I have to learn to make it works.
Very few folks ever bothered to use ODBC from within any Visual Basic of any stripe, be it classic/compiled/unmanaged VB 4 - 6, or .NET. ODBC is basically a procedural low level database technology - a standard really, and, high level RAD (Rapid Application Development) environments usually used RDO (Remote Data Objects), DAO (Database Access Objects), or ADO (ActiveX Data Objects). With .NET it would be ADO.NET.
Years ago for kicks and giggles I tried ODBC from VB6, and there is no problem with it, and I suspect one could even do it in .NET through PInvoke (Platform Invocation Services), but I never fooled with it. I have done a little .NET (more vb than C#), but not much. I have a really low opinion of interpreted code, basically, and would never personally use it for any reason. But that's just me.
Most folks who do databases from within any of the scripting environments within the Microsoft Office products themselves, or directly from VB6 or .NET no doubt use ADO. That's pure COM, and I'm really not sure what the low level implementation of it is, once inside the COM dlls, that is. What I mean by that statement is the proprietary stuff within the 'black box' itself. But anyway, its an object oriented view of database objects.
Like Computergeek alluded, COM from C or C++ is somewhat ugly. Microsoft tried to make things easier with their '#import' directive, smart pointer technology, and a bunch of ATL templates and macros. I've personally never gotten into that end of it, so I can't offer any advice there. One thing I was thinking of doing though was modifying some code I have that creates COM interface definitions by reading the typelibs of a component. That's essentially what ATL does and the above referenced #import directive.
The reason I just haven't done a lot of that in C or C++ is that I've always used C or C++ more for the data recorder programming I used to do in Windows CE, and that stuff wasn't database related. I've always used PowerBASIC for my desktop Windows programming, and within that environment its really easy to use COM. What is done there is that language product provides something termed their COM Browser. With that tool you browse to the type lib of the component, double click on it, and the environment reads the type lib and generates all the interface definitions that are then included in an include file. Then it takes just a few lines of code to get the COM object up and running.
However, one could do the same thing in C++. I haven't searched the internet but it wouldn't surprise me if lots of folks already did it. But maybe not. Maybe most or all folks doing C++ rely on ATL and the magic COM templates/macros involved in the #import thing. That's never really been an option for me because I don't 'cookbook' anything. I always like to figure out how stuff works 'under the hood', so to speak.
You seem to be aggressively jumping into learning a lot of stuff Lamblion. If you tackle COM I GUARANTEE that will slow you down some.
Years ago for kicks and giggles I tried ODBC from VB6, and there is no problem with it, and I suspect one could even do it in .NET through PInvoke (Platform Invocation Services), but I never fooled with it. I have done a little .NET (more vb than C#), but not much. I have a really low opinion of interpreted code, basically, and would never personally use it for any reason. But that's just me.
Most folks who do databases from within any of the scripting environments within the Microsoft Office products themselves, or directly from VB6 or .NET no doubt use ADO. That's pure COM, and I'm really not sure what the low level implementation of it is, once inside the COM dlls, that is. What I mean by that statement is the proprietary stuff within the 'black box' itself. But anyway, its an object oriented view of database objects.
Like Computergeek alluded, COM from C or C++ is somewhat ugly. Microsoft tried to make things easier with their '#import' directive, smart pointer technology, and a bunch of ATL templates and macros. I've personally never gotten into that end of it, so I can't offer any advice there. One thing I was thinking of doing though was modifying some code I have that creates COM interface definitions by reading the typelibs of a component. That's essentially what ATL does and the above referenced #import directive.
The reason I just haven't done a lot of that in C or C++ is that I've always used C or C++ more for the data recorder programming I used to do in Windows CE, and that stuff wasn't database related. I've always used PowerBASIC for my desktop Windows programming, and within that environment its really easy to use COM. What is done there is that language product provides something termed their COM Browser. With that tool you browse to the type lib of the component, double click on it, and the environment reads the type lib and generates all the interface definitions that are then included in an include file. Then it takes just a few lines of code to get the COM object up and running.
However, one could do the same thing in C++. I haven't searched the internet but it wouldn't surprise me if lots of folks already did it. But maybe not. Maybe most or all folks doing C++ rely on ATL and the magic COM templates/macros involved in the #import thing. That's never really been an option for me because I don't 'cookbook' anything. I always like to figure out how stuff works 'under the hood', so to speak.
You seem to be aggressively jumping into learning a lot of stuff Lamblion. If you tackle COM I GUARANTEE that will slow you down some.
No, I ain't going to tackle COM. Through my many forays I now know that there are enough SQL/SQL-C statements and conversions that I can do what I want to do. I also learned that it isn't going to be (I don't think) as complicated as I though.
Since I'm going to be actually creating the DB structure in Access, and adding a couple of starter records to it, and then distribute it with my app, all I will then have to do is add/delete/goto records in it.
Piece of cake! That is, once I perfect those techniquies. -:)
Since I'm going to be actually creating the DB structure in Access, and adding a couple of starter records to it, and then distribute it with my app, all I will then have to do is add/delete/goto records in it.
Piece of cake! That is, once I perfect those techniquies. -:)
@ OP: In that case I want to mention that there may be a memory or a connections leak present in ACCESS 2007. The size on disk of the DB Backend grows constantly and slows it self to a crawl, this simply means that the temp files for the DB need to be periodically cleared and the DB itself restarted but it can be a real PITA if that happens to be at 2 in the morning. I wish I could tell you more but this is something I've only been able to observe in my office, and since it's a production environment I can't take it down to mess with it. I can't even say for sure if it's ACCESS since we're getting to that through Sharepoint, but since this seems to be your planning phase it's something that you should watch out for.
I'm using Access 2010, and of course, everybody knows that Access 2010 is PERFECT -- the end-all, be-all in database design and productivity!!! -:)
I can't see that ever becoming a problem with the amount of data I'll be storing, but if it is, I'll simply close the DB, delete the lock file, then reopen the DB. Or, better yet, I'll probably check for the lock file on exit of my app and if it exists, I'll delete it anyway, as the DB will be just one small portion of my application.
If the DB needs to be compacted, well, I have no idea at this time how I would handle that outside of Access itself, other than run Access remotely from my website and maybe allow it to do it that way, but I hope it never comes to that.
I can't see that ever becoming a problem with the amount of data I'll be storing, but if it is, I'll simply close the DB, delete the lock file, then reopen the DB. Or, better yet, I'll probably check for the lock file on exit of my app and if it exists, I'll delete it anyway, as the DB will be just one small portion of my application.
If the DB needs to be compacted, well, I have no idea at this time how I would handle that outside of Access itself, other than run Access remotely from my website and maybe allow it to do it that way, but I hope it never comes to that.
Last edited on
Topic archived. No new replies allowed.