I'm currently living in 90's and I've been handed this piece of legacy code. I'm not knowledgeable when it comes to COM/OLE/MFC/ATL so I'm asking this, hoping that someone with experience from way back then, could help me to track down this issue.
What I have is this really old/legacy MFC/ATL application.
It launches, but eventually crashes in CFormView::HandleInitDialog (atlmfc\src\mfc\viewform.cpp)
The debug output I get is this:
CoCreateInstance of OLE control {6A24B340-7634-11D3-A5B0-0050044A7E1A} failed.
>>> Result code: 0x80040154
>>> Is the control is properly registered?
I know as much that this is due to some component registration failure, or resolution but what I do not know is how to figure out what this dependency is, I have a working old executable of the code, and maybe I could use a bit of reverse engineering to figure out if any DLLs are missing, but I really don't know, I have know idea what OLE is, and I would really appreciate some help on how to debug this.
that looks like it is dxDBGrid.dll. OLE is just Object Linking and Embedding. You need to find the dxDBGrid.dll and make sure it is registered. you can use regsvr32 to register it.
explanation of regsvr32
Related
Ok folks this is a long one, so please bear with me. I'll preface this by stating that I am -for all intents and purposes- a noob.
I'm trying to link to a running instance of a program (ETABS) using IronPython. The program has an API and decent documentation on how one can go about hooking into the running instance (EXAMPLE). However, their examples are for Python, C#, VB.net but not IronPython.
No biggie I thought, the Marshal module can be used to hook into it. So I tried this:
from System.Runtime.InteropServices import Marshal
csiApp = Marshal.GetActiveObject("CSI.ETABS.API.ETABSObject")
SapModel=csiApp.SapModel
Unfortunately I get errors on that last line - "ETABSObject has no attribute SapModel".
And yes, I've tried running it with csiApp.SapModel() as well with the same results.
So I delved deeper into it and apparently the object needs to be cast into another type - at least that's the way its been done for the C# example (LINK). Since - to my knowledge - we can't really cast objects around in Python (and yes, I've already tried clr.Convert) I came to the conclusion that the object being returned to Ironpython is a few abstractions removed from the object that I really need. Apparently comtypes can handle this automatically in the background (seeing as the python example works flawlessly). The code block below shows the object types returned to Ironpython and to pure python respectively:
Ipy : <System.MarshalByRefObject object at 0x000000000000002B [CSI.ETABS.API.ETABSObject]>
Python with comtypes : <POINTER(cOAPI) ptr=0x2e68d17f7c8 at 2e690b36a48>
I'm working on Ironpython 2.7.3 and can't really update it (for several reasons not relevant to this post). Would love to have advice on how to fix this or on how to install comtypes on Ipy.
So I think I've found the reason why this is happening - Ironpython cannot directly use MarshalByRefObjects (source) since Reflection doesn't work on these. It seems I'll need to create a C# class which can cast this object into the one I want, compile it into a dll and load that into my Ipy code.
I'll leave this here in case someone with more knowledge has a better answer.
I have a problem with several references in my VB.NET project.
For example I have this line of code:
Dim m As New Chilkat.Email
It comes from the library "ChilkatDotNet45.dll".
When I click on "References" and locate this dll, I can see that it has the settings "Use local copy" and "Do not include interop types".
When I switch to Release mode, the compiler tells me that "Chilkat.EMail" is not defined.
I have this problem with several DLLs, so it is not specific to Chilkat.
Can somebody tell me what I did wrong?
Thank you.
One of the standard approaches to solving any programming-related issue is trying to reduce the scope of the investigation. If you have a big project, in which something doesn't work, try to create a smaller project, and try to replicate desired functionality in it. Reduce as much as possible, down to a brand new project with maybe 5-10 lines of code in it.
If you were unable to solve your problem after making a reduced test case, now it's good time to post it on StackOverflow. I am usually reducing problems while writing a question on SO (not before, as one might think), constantly thinking "ok, is it minimized enough"; and this is how 90% of the questions never get posted - I often find a solution along the way of reducing my question to bare bones. :)
In your case, can you build a simplified project which has this problem and post a link here? We could then try switching Debug to Release on our machines and see if the we can reproduce. There are too many options to do the guesswork.
Could somebody please explain what cob32api does?
I have the task of migrating a batch cobol system from 32 bit Windows to 64 bit Linux. A large number of programs call 'cob32api' which belongs to Net Express. The Linux equivalent to Net Express is Server Express, but I'm not at all clear on what this particular call actually does. There don't appear to be any parameters required. Sadly, there are also no comments explaining what it's for.
Naturally I get an error when I try to build:
Load error : file 'cob32api'
error code: 173, pc=0, call=1, seg=0 173
Called program file not found in drive/directory
Can anybody help me out here?
Thanks in advance.
OK, I tracked down a colleague who has worked on this stuff and knew what it meant. The call to cob32api is required so that the cobol program in question, as well as any sub-modules, can call Windows APIs. This explains why the corresponding library (cob32api.dll) has no Linux equivalent.
The simple solution to my problem: Remove the call altogether.
I hope this helps anybody who runs into a similar problem.
Thanks for the comments.
Additional information:
The removal of the "cob32api" call had consequences for the sub-modules I mentioned. Ther were a number of calls of the form
CALL WINAPI "windows-function-name" ...
These resulted in later compile errors and therefore needed to be replaced.
I'm becoming mad trying to figure out how to resolve this task. My goal is pretty easy, copy a file on the USB stick every time that it is inserted and then release the USB stick turning off the LED. What is the best way to solve it?
1) I found this article
http://geekswithblogs.net/BruceEitman/archive/2008/06/13/windows-ce-monitoring-for-disk-insertion-to-add-support-for.aspx
or
http://geekswithblogs.net/BruceEitman/archive/2008/06/13/windows-ce-monitoring-for-disk-insertion-to-add-support-for.aspx
but I can't translate it on VB.NET project.
2) Then I read that is enough to use RequestDeviceNotifications for block devices. But How can I do that in VB.NET?
I would like to avoid OpenNetCF if possible.
Thank you
Since you don't want to "use OpenNETCF" I assume that you don't want to use any libraries or capabilities not built in to the CF. We'll skip the argument of that silliness and the "value of your time" discussion and take that as a requirement.
What you need to do is:
Use P/Invoke to call CreateMsgQueue. That's going to give you back a Handle. You'll probably want to do CloseMsgQueue as well for completeness
P/Invoke RequestDeviceNotifications and pass it the handle returned from #1 above along with the DEVCLASS GUID value for the device notifications you want - probably STORE_MOUNT_GUID. Again, adding StopDeviceNotifications for completeness is a good idea.
At that point you'll get a message on the queue whenever a insert or remove happens. You then call ReadMsgQueue to get the DEVDETAIL data in the message.
Parse the DEVDETAIL and look at the fAttached member.
It'd take me a while to write that for you, so you'll need to do this on your own.
Start writing the project, find P/Invoke routines for the calls you need (like FindFirstFile and CreateProcess). On SO, have a look at Storage Card Problem In windows mobile and How to register form for WM_DEVICECHANGE message in windows mobile.
You are only going to be dead in the water if you can not find a particular call that you can't make.
As you work through your project, post (or search for) the actual problems you run into.
Otherwise, it sounds like you are asking someone to write the project and hand it to you.
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).