Here is my scenario. I am using Quicktest Pro (VB) to create an ActiveX object from a Labview VI that I built into an executable. In the build specs of the VI I have enabled ActiveX server option (ActiveX server name: "MyLabviewProgram") and in the VI Tools>Options>VI Server: Configuration the ActiveX box is checked.
So in QTP my code is:
Set IvApp = CreateObject("MyLabviewProgram.Application")
Set Vi = IvApp.getVIReference("MyLabviewVI.vi")
Vi.Call ParamNames, ParamVals
Upon running this I get a Run Error on the first line:
ActiveX component can't create object: 'MyLabviewProgram.Application'
I am having trouble figuring out why it errors. From National Instruments website they have a step in on one of their community pages about "LabVIEW Executable Used as ActiveX Server". The step is after building the EXE, 5. Run the EXE at least once on the target to activate the .TLB file. I've run the executable but not sure what they mean by on the target.
Does anyone have a suggestion on what I need to do to get this working?
Your description sounds like you correctly created a vi .exe. "On the Target" probably means "On the Target PC". The EXE adds all COM registration entries to the Windows registry each time it is executed.
It sounds like you haven't verified the COM registration entries are present in the registry yet. That's the first debugging step.
Run regedit.exe and search for MyLabviewProgram.Application under the HKEY_CLASSES_ROOT sub-key. You should find an entry that contains a sub-key that contains a value that contains a GUID (a large hexadecimal number).
That "class ID" GUID should be referenced under the HKCR/CLSID key. That reference should contain a LocalServer32 sub-key with the default value pointing to your application's .EXE filepath with the /Automation argument appended.
It seems likely that one of these steps will fail. I can't say exactly which one without more information.
Related
Windows 8 has a feature: it can launch an application from the search panel (on the right side of the screen). It works like following:
Developer registers his or her application following this instruction. It is a bit legacy instruction, but the project I participate in uses this way to register its settings.
At user logon Windows creates (if none exists) a special .xml file in C:\User\<UserName>\AppData\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState\Indexed\Settings\en-US with content shown below. This file has extension settingscontent-ms
As soon as user clicked on this file, the system launches the specified application (actually explorer calls for it, as I discovered by ProcMon).
Xml file content:
<?xml version="1.0" encoding="UTF-8"?>
<PCSettings>
<SearchableContent xmlns="http://schemas.microsoft.com/Search/2013/SettingContent">
<ApplicationInformation>
<AppID>windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel</AppID>
<DeepLink>%Canonical name or application path%</DeepLink>
<Icon>%App path%,-%Resource number%</Icon>
</ApplicationInformation>
<SettingIdentity>
<PageID>%GUID as in instruction above%</PageID>
<HostID>{7E0522FC-1AC4-41CA-AFD0-3610417A9C41}</HostID>
<Condition>shcond://v1#RegkeyExists;0;Regkey;HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\%GUID as in instruction above%</Condition>
</SettingIdentity>
<SettingInformation>
<Name>#%App path%,-%Resource number%</Name>
<Description>#%App path%,-%Resource number%</Description>
<HighKeywords>%App decription%</HighKeywords>
</SettingInformation>
</SearchableContent>
</PCSettings>
We can see node with the name HostID. Windows writes specified in code GUID to this node, but it breaks the ability of my application to work. If I try to execute my app through this "shortcut" by clicking on xml file or chosing my app in search panel, the system shows me a message: "Unspecified error".
When I manually change the HostID value to {12B1697E-D3A0-4DBC-B568-CCF64A3F934D}, it starts to wrk fine.
I looked through registry in order to find something about these two GUIDs, but I didn't find anything. Also I looked for the difference between registry values corresponding to my app and to another, but working, app and didn't find any significand differences too.
Also I tried to delete this file and login into the system under ProcMon, I caught some moments: explorer tries to open the file and fails with ERROR_FILE_NOT_FOUND, explorer creates missing file, reads registry and writes something to created file, then it closes the file. But I didn't find anything interesting in between of these messages, that can help me to solve my problem.
I found out that registry key HKEY_CLASSES_ROOT\CLSID\%App GUID%\System.ApplicationName contains exactly the same with DeepLink tag (it was the first error in my app - specified key was empty), but the proble with "wrong" HostID remains.
Does anyone know, what it is and how to make Windows to write the rigth GUID to this tag, or at least some useful info about this tag? I just can't imagine anything else to change, but I think, that I need to change something in corresponding to my app registry keys.
I found the solution: just put app's GUID (the same as in PageID) into DeepLink.
To do this, you need to write this GUID as string value to HKEY_CLASSES_ROOT\CLSID\%App GUID%\System.ApplicationName.
That's the solution. However, I haven't found the meaning of HostID tag :(
Is there an easy way of generating the memory dump for the crashed application?
I have a situation in which the customer received the code which is generating the crash, as the code itself has no signal handlers for the backtrace generation on abort I was wondering if there is an easy way of telling windows to generate the memory dump of the crashing application.
Ideal solution wouldn't involve the installation of the debug tools (or the code modification) but if this is not possible, it would be really helpful to know.
One simple way to dump memory when application crashes is by using windows taskmanager.
When ever an exception or an application error occurs windows pops up an memory dialog and shows the address location which was causing a crash.Before you click ok on the message box open Task Manger and right click on the crashed application and select Create Dump file.Take a look at the screen shot below.
Select the file
2)Another way of generating user mode dumps is by adding the following registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting >\LocalDumps\application.exe
application.exe should be replaced by the application name which is under scanner.
under this key following values can be added
DumpFolder
The path where the dump files are to be stored. If you do not use the default path, then make sure that the folder contains ACLs that allow the crashing process to write data to the folder.
For service crashes, the dump is written to service specific profile folders depending on the service account used. For example, the profile folder for System services is %WINDIR%\System32\Config\SystemProfile. For Network and Local Services, the folder is %WINDIR%\ServiceProfiles.
DumpCount
The maximum number of dump files in the folder. When the maximum value is exceeded, the oldest dump file in the folder will be replaced with the new dump file.
DumpType
Specify one of the following dump types:
0: Custom dump
1: Mini dump
2: Full dump
CustomDumpFlags
The custom dump options to be used. This value is used only when DumpType is set to 0.
The options are a bitwise combination of the MINIDUMP_TYPE enumeration values.
I have found the answer myself, the msdn specifies the debug registery in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error\LocalDumps
The following values need to be set:
DumpFolder
DumpCount
DumpType
CustomDumpFlags
The extensive documentation is available here.
If the registers do not exist it is possible to create them manually and windows will pick it up.
Also this is possible without directly modifying the registry with following steps:
Click Start, and then click Control Panel.
Double-click System, and then click Advanced system settings.
Click the Advanced tab, and then click Settings under Startup and Recovery.
In the Write debugging information list, click Small memory dump (64k).
I have a VB6 project that I didn't create but I have to update, when I go to make the exe I get a compile error: Method or data member not found, and it points too "SCom1.FileReceive" in the code below. When I look at the Main form, the SCom1 control is a PictureBox.
This code has been working for the last 5 years but I don't know why SCom1 is a picturebox, or why I'm getting the error, is it a reference? SCom1 to me looks like a MSComm function? Let me know if anyone has any ideas, I just don't know VB enough to know how to troubleshoot this. Thanks
If SCom1.FileReceive = True Then
WriteToLog (Now() & " FileReceive was true, now false")
SCom1.FileReceive = False
End If
The machine which you have opened the code doesn't have the mscomm32.ocx file or the ocx file not registered properly.
When vb cannot reference an ocx, it'll convert the relevant control to a picture box control.
What you have to do is, close the project without saving. Then open system32 folder and check for mscomm32.ocx file. If the file is not there then you have to download that from the intenet. The register the file using regsvr32 command in command prompt.
After this you can open the vb6 project and start working.
=========================================================
EDIT : Included the update in the comments to the answer, this will help other users in the future... :-)
if the method name doesn't look familiar to a known ocx file (in this case the SCom1.FileReceive), the missing component can be a custom ocx file.
So check on the working machine or in project folder whether there are any ocx file exists in the relevant name (in this case SCom.ocx).
if there is a file exists in such name, register that file using regsvr32 (if not registered), then add that to toolbox, then replace the picture box control with the relevant control (make sure the name tally).
On one computer 'A' (win vista 32 bit) if I run my program in debug mode all the richtextbox controls throw 'property cannot be set' errors.
I can go on to build the exe (without error ) and the full application OK
But when I then install and run the application on this computer or on computer 'B' (win xp) the same problems occur on both.
However if I run the exact same code in debug mode on computer 'B' there are no errors.
If I build and install the application on computer 'B' it works fine. If I then install this application on computer 'A' it also works fine.
When putting together the application for distribution, both computers use identical copies of richtx32.ocx (it, like the code, is checked out from the same repository).
If I check out previous copies of the code on computer'A' (that used to previously behave OK) they also now exhibit the same problems as the latest version of the code.
I don't have a clue what's going on, please help!
I'm seeing multiple references to the Property cannot be set message being resolved in the version of the Rich Text Control that is distributed in Visual Studio 6.0 Service Pack 4, and another Property cannot be set message fixed in SP5.
First and foremost, make sure that a minimum of SP5 is installed; I'd just go with SP6.
For reference, my Microsoft Rich Textbox Control 6.0 (SP6) is at C:\Windows\System32\RICHTX32.OCX, and is version 6.1.97.82.
I know you said that both machines have the same copy of the control installed; for the sake of completeness, you may want to double-check that the new control was registered after installation.
EDIT:
I exported the HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402} reg key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}]
#="Microsoft Rich Textbox Control 6.0 (SP6)"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Control]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A52-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A53-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A57-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED4-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\InprocServer32]
#="C:\\Windows\\system32\\RICHTX32.OCX"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus]
#="0"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus\1]
#="131473"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ProgID]
#="RICHTEXT.RichtextCtrl.1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ToolboxBitmap32]
#="C:\\Windows\\system32\\RICHTX32.OCX, 1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\TypeLib]
#="{3B7C8863-D78F-101B-B9B5-04021C009402}"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Version]
#="1.2"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\VersionIndependentProgID]
#="RICHTEXT.RichtextCtrl"
A bad richtx32.oca file in the system32 directory seems to have been the cause of this.
Here's what an .oca file does:
Some of the properties of the control are provided by the framework
and some by the control itself. Programmatically, the properties from
the framework and the control all appear as properties of the control.
In order for these properties to appear, Visual Basic creates an
extended type library when the control is loaded into the toolbox.
Because the process of reading the control's type library and creating
the extended type library is time consuming, Visual Basic caches the
extended type library information into an OCA file.
If you delete the OCA file for a control Visual Basic recognized,
Visual Basic will recreate the .OCA file when you load a project
requiring the control. This recreation process comes with a time
penalty.
So it seems that having a bad .oca file in existence can mean that the properties of the control both in the IDE and in the compiled .exe will be affected.
The solution is to delete the .oca file in the system32 folder and then load the project again.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html