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.
Related
I am migrating vb4 application to vb6.0 app. I am using windows xp. I want to add ocx controls to the application. Any simple steps to do add ocx controls/files to the application. What are .frm files
Object = "{bla-lablabla-lablabla}#2.0#0"; "THREED20.OCX"
Object = "{blabla-bla-bla-blabla-blablabla}#2.0#0"; "vsview2.ocx"
I want to add these two ocx controls in vb6 ( 16 bit to 32 bit)
You don't state if you already have the OCX files.
To address your first question on how to add OCX controls to your VB6 project. You need to go to Projects -->Components( CtrlT ) then click the Browse button and navigate to where the OCX is located and select it.
As far as the actual OCX Files are concerned there is a Threed20.ocx that is included on the VB6 install media, I believe it is on Disk 2. There is also a registry file that you will need to run to enable design time use of the control. As far as the vsview2.ocx file is concerned if it is not a 32 bit OCX you will need to contact the vendor, who I believe is ComponentSource to get the proper version if you don't currently have it.
And as far is what is a .frm file it is according to this article
A form holds the description of all objects and their properties for each form, as well as the basic code that you have written to respond to the events.
I have a C# program which I made in Visual Studio. When I right click on my program executable in Explorer and click Properties>Details it says "Copyright © Hewlett-Packard Company". To troubleshoot I then created an empty Console Application, and it has the same copyright message.
Does anyone know how to fix this? I have tried some tutorials about regedit but they did not work.
Check out the Assembly Information dialog in your project properties.
In Solution Explorer you can right click on your project and select Properties. An Assembly Information button is in the Application tab.
I haven't tried this, but to change the default value, use regedit to modify
HKLM\Software\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization (x64 systems)
The answer by #Louis is correct. I'm just posting this to add some background information, and to vent my frustration at Hewlett-Packard for creating this stupid situation.
If you buy a Hewlett-Packard PC with Windows pre-installed (which is typical, unless you're in the IT dept. of a company that wipes the hard disk and installs a preconfigured disk image) then Hewlett-Packard has stupidly installed Windows with their name as the owner and owning organization.
Here are some links. I'm surprised there aren't even more frustrated customers complaining about this.
https://www.besttechie.com/forums/topic/11774-change-the-name-of-the-registered-owner-on-an-oem-machine/
https://www.groovypost.com/howto/howto/change-the-registered-owner-and-company-name-in-windows/
- see the comments
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/12fdb09b-472b-4634-991c-670e5f775365/upon-new-project-hewlettpackard-is-always-placed-in-the-assembly-company-name-field?forum=visualstudiogeneral
https://support.hp.com/in-en/document/bph05548
- is obsolete, doesn't include x64 registry entry
So the solution is to do this, as soon as you power up the new HP machine (otherwise this owner information will "pollute" all the programs you install):
Fix the RegisteredOrganization and RegisteredOwner registry information at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
If it's an x64 machine (and all machines are now), also fix the RegisteredOrganization and RegisteredOwner registry information at HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion
I'd imagine you're looking for the AssemblyInfo.Copyright Property. In order to modify this simply find the assembly.info class and modify it appropriately.
If you can't find it you can also use the Assembly Information Dialog as suggested by #Louis, which modifies the file for you.
Working on writing a custom property Handler for our custom file type in windows 7. I have installed the Windows 7 SDK and built the sample Property Handler. After registering the handler, it works great in Windows Explorer, but in the common file open dialog the custom values do not appear. Does anyone know if there is something special I need to do to get the properties to appear in common dialogs?
Explorer:
File Open Dialog:
OK, figured it out. Here is the deal. My app is 32 bit and I am on a x64 system. Because the PropertyHandler is written in x64 to support the shell out of process. But for the file open dialog it needs to run inprocess, so the x64 dll can not run. I confirmed this by creating a quick x64 app and the fileopen dialog works the same as the OS. Hope this helps someone else in my shoes later on, hate answering my own question, but don't want people wasting NRG on this one as I found the solution.
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.
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.