I have a legacy VB6 application that I need to make a simple change to until the replacement application is ready. When compiling, I get an error telling me that one of the controls I have included is unlicensed. IS there an easy way to tell which one? I have already gone through and run vbctrls.reg as well as, registered the ocx files, anibtn32, dbgrid32, gauge32, graph32, grid32, keysta32, mschart, msoutl32, spin32 and threed32.
Any help would be greatly appreciated.
One approach is to create a new sample project, and add one control at a time to that project. Run it for each one until you discover which control (or controls) are producing the error.
Related
I am working on greatly simplifying an old MFC application, and I'd like to use that opportunity to remove a dependency on a certain third-party ActiveX library that has been causing headaches. I first simply tried to remove all references to these controls in the cpp code. It compiles fine, but when installed on a new computer, it crashes if the library .msm file is not included in the setup project.
The problem now is that I don't know where any remaining references to these objects in the project is, and therefore have no easy way of tracking them down and removing them. Simply using the Find-functionality in VS only returns results in cpp files which I've already cleaned up, not any control instances in f.ex. dialog resource files. Is there a way to search for all these objects in the project, or check for them compile-time so that I can use compile errors to see where any library objects remain?
First of all: CoCreateInstance, CoGetClassObject are the normal ways how COM Objects are created. Should be easy to set break points here or to set a hook to monitor what's going on.
Seams that you have a bad error handling in you software. Otherwise you application should show an error message if an object could not be created.
Try to debug.... use remote debugging, even a crash dump will lead you to the code location.
Easiest approach: In your development machine. Try to look into the output window and see if any of the old ActiveX DLLs gets loaded. Trigger down to the location were any of those objects is created.
You can do the same with remote debugging on the test machine.
I've been through the Windows and Mac video tutorials on the FireBreath (FB) website, through all the documentation and even seen the ActiveX example that a person has provided.
It's been an entire week, but I still can't understand how to create a new project in FB. The only thing explained on the website is how to get the FB sln compiled, where the PluginTest example is already coded. Even for the ActiveX example, only the code is given. It isn't explained as to how they created the project.
So how do I create a new project in FB? Should I just take the existing FB sln file and create a new empty project in it? How do I know what classes I should add to the project? How do I edit cmakeLists.txt to recognize my project? How does running prep2010.cmd make my newly added project compile?
If I need to create a wrapper for my ActiveX, how do I go about creating that project in Windows?
If you have been through the windows video tutorials and didn't see how to create a new project then you were obviously not paying attention. The first video tutorial on both windows and mac tells you how to use fbgen to create a new project.
To get text instructions, you can find them fairly easily:
Go to http://firebreath.org and click on "Getting Started". Scroll down to "Creating a new plugin project" and click on the link.
Either method will walk you through essentially the following steps:
1) Install cmake, visual studio, and python (if you don't have any of them)
2) Get FireBreath (the video tutorials suggest using git; I made the tutorials, so you can guess my suggested method).
3) Run fbgen.py with python and follow the steps.
Congratulations! You have now created a new plugin project!
To build it, you'll need to run the prep script appropriate for your platform and then open the build/FireBreath.(sln | xcodeproj) file in (visual studio | xcode). Note that this differs a bit depending on whether you're on Windows or Mac.
The prep script (such as prep2010.cmd) does not make your project compile; instead it uses cmake to generate the project files for that project for your computer which can then be used to build the project, as explained in the pages linked above. You should never modify anything in the build directory directly, instead you should modify the CMakeLists.txt file in your project directory or if you have platform-specific changes you need to make you can modify Win/projectDef.cmake and Mac/projectDef.cmake.
FireBreath.org is a wiki, so feel free to help us make these things easier to find; as you can see from the links all of the information is there. To me it seems easy to find, so obviously I'm not a good one to try to fix the problem (since I can't see it).
As for making an ActiveX wrapper, there is an example of doing this but it's not really something that is just "easy to do". FireBreath does not in any way attempt to make this a simple thing to do -- that's not the purpose of FireBreath. FireBreath is simply a framework for creating browser plugins; if you want your plugin to act as an activex wrapper you'll have to implement all of the activex for containing your control yourself.
Hopefully that's enough information to get you started. If you are confused, please go read those links. If you're still confused, read them again -- all of this information is there. If you're still confused, come ask in the FireBreath chat room on IRC and I'll try to help you figure it out.
I read something about PowerWrap which is supposed to allow you to static-link a vb6 .exe to it's dependent files (.OCX, etc.)
However, the website for the product appears to be just a squatter.
Anyone know anything more about the product or something similar that's still being supported?
I discovered another solution called UMM (Universal Make My Manifest). You give it a list of files and some options, and out comes a manifest ready-to-go. I've been using it for a half-million line VB project with dozens of ActiveX modules, and it works well. Requires tlbinf32.dll.
I have created a Silverlight class library which holds a lot of the common utility methods I use day to day in my Silverlight development.
I am starting to play around with Workflow and would like to reuse this common dll. After referencing this dll in my workflow project I see a yellow warning icon beside it.
I can use the functionality from this dll when creating ‘Code Activities’ without issue. After adding the using statement for it all works AOK.
using EquinoxeAISManagementSystem.Common.Helpers;
BUT when I try to import the dll from the activity designer, I do not see the dll in the import window.
If I edit the XAML and add it directly, I get a warning.
Is it possible to reuse Silverlight dlls?
I believe I can answer my own question.
The project EquinoxeAISMAnagementSsystem.Common is part of another solution. I had added this single project for the other solution into my new workflow solution (which I was having this issue in).
When I added the reference to the EquinoxeAISMAnagementSsystem.Common.dll initilly, it was by referencing the project in the workflow solution.
This seems to be the cause of the issue (for workflow anyway).
I was able to correct this issue by adding the EquinoxeAISMAnagementSsystem.Common.dll to a common folder where I keep all my external dlls (for ease of use).
..\Projects\EquinoxeAISManagementSystem.DLL\
I set up the output destination folder for this EquinoxeAISMAnagementSsystem.Common project to the folder above. I was then able to add the reference to Common.dll by browsing directly to the folder above.
Hay presto, all works.
I’m not sure id this is the ‘correct’ way to do things, but I needed to get over this hump.
I would be interested in anyone’s comments and if there is a correct(er), why to fix this issue.
Thanks ….
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.