I have a COM DLL, coded in Delphi. It should be invoked via an Active X control when a web page loads in MS IE (via soem JavaScript on the page).
Btw, this all works fine with an existing serial port interface, but I am recoding teh DLL to read from USB; all else is unchaged.
It works fine in the Delphi IDE, but not "in the field". The active X control should request it to read some input from a USB port and should then send that to the web page.
Reading from the USB device works, as I can open Notepad and see the value being written there.
The DLL will display a form, and a dialog box, and will write to the system debug trace. Since I am seeing none of these when loading the web page in MS IE, I think we can assume that Aective X control is not calling into the DLL.
In MS IE I have enabled all Active X options.
in c:\Windows\System32 (which is equivalent to c:\Windows\SysWOW64), I have regsvr32.exe -u my_dll.dll and then regsvr32.exe my_dll.dll both of which the system announced to be successful
I searched, and there is only one copy of my_dll.dll under c:\Windows
and it has the correct size and date/time
my %path% is %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem; for system and empty for user
Any idea what I am doing wrong? Or how I can go about tracking it down?
If you are loading the ActiveX control in webpage through javascript, you will have to package the control for web deployment. See this example for how to do this in your javascript and check whether you have done properly it or not:
Calling Activex Control 's Functions from javascript
Once you do the above thing correctly and open your website in IE, the web-page will at least "load" the ActiveX control. Beyond that, you can display message-boxes or write logs in your Delphi code to track down the actual coding issues.
Related
We have an application that currently works on IE browsers till IE10version.
We have a challange to move towards IE11 as VB support is removed from IE in standard mode.
We had lots of VB scripts that were converted to JScripts. The application also loads VB6 active x components.
After conversion from VB script to JScript, the application runs fine except in places where VB6 active x components are being loaded.
The application crashes every alternate time with "out of memory" issue and does not load the ocx file.
Note: this happens every alternate time.
I used ProcMon tool to see what was happening. I see when the active x component is loaded, the ocx file is loaded and another dll MSVBVM60.dll is also loaded. when the active x component is Shutdown, the MSVBVM60 is also cleaned up along with that.
The next time when we try to load the active x component, the ocx file and MSVBVM60 are not loaded at all and we see the out of memory issue.
We tested the application by opening and closing the active x control once and then waiting for around 30 seconds and then try launching the active x control. This time it worked. With this we felt the component is taking time to shutdown/unload.
If we try to launch the control before it shuts down, the application is giving that error.
This never happened with VB script code.
Is there any relation with MSVBVM60.dll with VBScript that makes it to unload faster compared to JScript?
We could not find any code specific that was different in VB script and JScript.
I need your inputs to think in the right direction. Please help.
I have to travel back in time and debug a VB6 form. It is used inside an application (not ours, Esri ArcMap.exe). I see VB6 has some debug capabilities, but nowhere do I see, like in .NET, the ability to "launch another app" or "attach" to a running application.
How can I debug my VB6 code while running inside a 3rd party application?
It's right there; you just didn't see it.
If your form is hosted inside a DLL (most likely from your description), you have two options, both of which can be set from the "Project"-> "Projectname Properties" dialog box, Debugging tab.
"Wait for components to be created"
When click on Run (F5), VB6 will alter the registry entries for your DLL so that they point to the VB6 debugger.
Launch your third-party program as usual.
When any program tries to create objects and forms hosted by your DLL, it will do so through the debugger.
"Start a program"
Same as before, plus VB6 will execute the command line entered in the dialog box.
It should be noted that VB6 must be run in full "As Administrator" mode, because it needs to write to normally-protected areas of the registry.
Don't worry about the third option. Let's just say that some things are better forgotten.
My first-hand knowledge is a little hazy (I've inherited a PC with all of this stuff configured, and I have no intention of ever setting it up again from scratch...), but here goes:
There is an ESRI VB6 add-in called ESRI Compile and Register, which is supposed to make this whole process a lot easier.
There's a lot of instructions on that link, but one of the key things is under Options->Support Visual Basic Debugger, which creates a file ESRIVBDebugHelper.exe.
In Project -> Properties -> Debugging tab, under Start Program, you enter the full path to this ESRIVBDebugHelper.exe. Then when you debug the VB6 application, it should spawn ArcMap and allow you to debug on the fly within the VB6 IDE.
I have a VB6 application, the installer is compiled using INNO Setup.
The installer runs fine. But in about 10% of computers when the user clicks the Icon to run the installed app, it doesn't start, no error message, only a Beep sound.
This is happening on XP and also Win 7.
I develop in XP and Win 7 and the application works OK, so I haven't been able to reproduce the issue.
The installer registers all ocx and dlls needed (afaik). (Well not completely all, it assumes MS run-time components should be there, but I guess an error message should show up if something is missing)
I was thinking some kind of user permissions, UAC, but even users in the admin group have had the issue.
Could you point me to what possible issues to look for and test in order to patch the app.
Thanks!
[FOLLOW UP]
Thanks to the tips, found out the manifest is causing the problem. I use it to make the controls look better:
http://www.vbaccelerator.com/home/vb/code/libraries/xp_visual_styles/using_xp_visual_styles_in_vb/article.asp
Now I'm trying to discover why. I have another application with the same manifest and that one works ok.
Haven't been able to get feedback on the event viewer yet.
The "beep crash" often points to an error in an application manifest such as an XML syntax error or namspace conflict. Event Logs will often provide a hint about this.
But I've found that people often try to use the Common Controls 6.0 Library without ensuring proper library loading sequence.
Before any Forms are openend you should load shell32 and then comctl32. The easiest way is a couple of no-op calls in Sub Main:
Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32" ()
Private Declare Function IsUserAnAdmin Lib "shell32" () As Long
Private Sub InitCommonControlsVB()
IsUserAnAdmin
InitCommonControls
End Sub
Private Sub Main()
InitCommonControlsVB
Form1.Show
End Sub
Without this your program will usually work fine in Vista or Win7, but will fail on some XP service pack and patch levels. Part of this is due to changes over time in the Fusion subsystem that handles SxS activation and comctl32.dll patches.
Ignore those saying you need to call InitCommonControlsEx(), it isn't necessary unless you are constructing and using Win32 controls directly instead of VB6 and COM controls.
A few things to try to narrow it down:
Check the Windows Event Log for crash events
Check the Windows Event Log (in the Application section) for crash reports from your application. You can quickly get to the log viewer on Windows XP by clicking Start > Run, typing eventvwr and pressing Enter. On Windows 7, you can type "event viewer" in the search box that is in the Start menu. You can filter the events to only show error events from your program.
You might find a few error events on one of the computers where this problem has already occured, because it sounds like the error reporting feature is turned off on these computers (in which case "hard crashes" like access violations are logged in the Event Log instead of displaying an error dialog to the end-user, as long as a debugger isn't installed on the computer).
Make sure "Error Reporting" is turned at the OS level
As mentioned in the previous section, it sounds like the error reporting feature is turned off on these computers. In that case, a crash won't display any kind of message to the end-user at all and the application will just vanish suddenly. In Windows XP, you can check this setting (and turn it on) as follows:
Right-click "My Computer" and select Properties.
Open the Advanced tab and click the Error Reporting button.
Select the Enable Error Reporting option.
Click OK to all the open windows.
Add trace code to your application
You could also add some trace code to your application's start-up code, such as code to display a message box or write a message to the Windows Event Log or to a log file as soon as your application starts (for example, in the Form_Initialize event of your main form, or in a Sub Main routine).
This way you will be able to tell whether your application is crashing before or after the VB6 runtime is loaded: if you try to start the application and it disappears/crashes, and your startup message isn't logged, then you know it's crashing before it even has a chance to get to your application's startup code, which could indicate that a dependency of the VB6 runtime or the VB6 runtime itself is not installed properly.
Note that Windows XP and Windows 7 both ship with the VB6 runtime pre-installed, but it's possible for misbehaving installers to overwrite or remove files that are part of the VB6 runtime.
We have a legacy VB6 application which has worked just fine on Windows XP Professional SP 3 until just recently when we added an IE frame control so that we could display static local HTML files on a form. And, it works fine until I go to close the application. And, then it reports the following error message (consistently):
Faulting module ntdll.dll, version 5.1.2600.5755, stamp 49901d48
Here's the reference in the Visual Basic project file:
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
And we use it by performing the following actions:
Development machine is running Win7 + Vb6 IDE.
Add a component reference to the "Microsoft Internet Controls" located at C:\Windows\SysWow64\ieframe.dll
Place a control on the form at design time.
Show that form modally by calling Form.Show vbModal The error happens when I use the default form instance frmMyForm.Show vbModal as well as when I use a local instance Dim MyForm as New frmMyFormMyForm.Show vbModal
Call WebBrowser.Navigate "staticPage.html"
When the user presses a button, the button click event returns the user choice and the form is disposed of.
Exit the application -- Here's where I get the error.
I've been looking all over the web, and haven't been able to find a whole lot of people still trying to use VB6 in this way. So, I'm wondering if someone might be able to help me on stackoverflow. Any help is much appreciated!
[Update] And, the plot thickens. I made a sample application with just that web component in order to make sure that it was causing the error. But, I didn’t experience the error when it closed like I was when exiting our existing/legacy vb6 application. I'll do a bit more investigating.
A follow up to this in case any runs into the same issue (the original poster and I were coworkers at the time)...
The application was using the VBCorLib library, and some of its string manipulation classes utilized direct memory access incorrectly. Read more at this VBCorLib forum post.
It turns out that the issue was that I was trying to delete the temporary file that the browser had loaded. It works now that I've moved that delete file code to the form unload event.
I have created a Windows Shell Extension using ATL (Visual Studio 2008). It has the following modules and each module is a separate ATL Simple Object with its own .rgs file for registration:-
IShellFolder/IShellView -> For a virtual drive in windows explorer
IContextMenu/IShellExtInit -> For a popup menu files and folders
IShellIconOverlayIdentifier - To display overlay icons on files and folders
IShellPropSheetExt/IShellExtInit -> For a custom property page in File & Folder's properties
The above work fine in WinXP and I am able to debug this shell extension in WinXP. But a soon as I switch to Vista, I only get method calls for (2) and (4). The drive gets created in Windows Explorer but the underlying methods are not called when I click it.
Although when I right click I get called for (2) and when I select "Properties" for a file or folder I get into the code for (4).
Is there some interface that I am missing for (1) and (3) on Vista. I could not find full and detailed documentation on writing Shell Extensions for Vista on MSDN. I had already gone through the CodeProject articles on shell extensions.
The problem was because of a Xml SMART Pointer usage. It was has problems when Release() was called on it.
Check this link
Internet Explorer crashes when MSXML2::IXMLDOMDocumentPtr -> Release() is called
Make sure that your extensions are handling the initialization properly, otherwise the verclsid.exe won't let your extension getting loaded.
verclsid.exe first loads the shell extensions and does a quick check on them before it sends an 'ok' to the shell indicating that it's safe to load the extension.
See here for some details about verclsid.exe.