Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
If I understand correctly,...
1) I put CCR32.OCX into a Win7x86 C:\Windows\System32 and registered it.
2) Open VB6, create a project with CCR32.OCX, put some of the controls on the form.
3) I add CCR32SideBySide.res into the project so that this file will be compiled into the exe.
4) I copy Project1.exe and CCR32.OCX to a thumbdrive and plug into my Win8x64 ASUS notebook.
5) I copy the files onto the desktop. (Same result if I just run from thumbdrive).
6) I run Project1.exe
Error:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
Windows Event Viewer:
Activation context generation failed for "C:\User\...\Desktop\Project1.exe". Error in manifest or policy file "C:\User\...\Desktop\Project1.exe" on line 36. Invalid Xml syntax.
I did the same for CCR32SideBySideAndVisualStyles.res and same thing. This time the error in on line 41.
On Local Error Resume Next: If Not Empty Is Nothing Then Do While Null: ReDim i(True To False) As Currency: Loop: Else Debug.Assert CCur(CLng(CInt(CBool(False Imp True Xor False Eqv True)))): Stop: On Local Error GoTo 0
Re: CommonControls (Replacement of the MS common controls)
I tried that before some time back, and another one I cannot remember the name. Did not work for me. Actually now I don't need this as I prefer the Krool's trouble-free non-OCX version. I am helping Krool to test out his Reg-Free OCX solution for others' preference of choice. Since I can help (in testing) since I have Win8, I will help.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
I tried that before some time back, and another one I cannot remember the name. Did not work for me. Actually now I don't need this as I prefer the Krool's trouble-free non-OCX version. I am helping Krool to test out his Reg-Free OCX solution for others' preference of choice. Since I can help (in testing) since I have Win8, I will help.
You said it also dont work on Win7...
By me its working. Can somebody else test?
Re: CommonControls (Replacement of the MS common controls)
It works for me on Win7 32-Bit. I used your compiled OCX, then created a project with a component reference to it, added the .RES file and a couple of controls, compiled, and ran with the OCX and the EXE in the same folder on a different computer. No problems.
Re: CommonControls (Replacement of the MS common controls)
Finally able to upload attachment to the forum here. Hope I am doing it right becos can't seem to find where to attach in PM. The only file nt in the zip is the OCX that I downloaded from this link:
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
Finally able to upload attachment to the forum here. Hope I am doing it right becos can't seem to find where to attach in PM. The only file nt in the zip is the OCX that I downloaded from this link:
Ok, now it get's funny.
First, I got the same error. (Side-by-side configuration error)
But then I just recompiled the project again (build Project1.exe) and then it worked. Huh?
Recompiliation was done under WinXP SP3 (VM) and then tested on Win7. Just for info.
Re: CommonControls (Replacement of the MS common controls)
Same vbp, frm, res and ocx. The only diff is my compile vs your compile. Is there any required (system) file that is required for the compile not in my system but in yours? Or diff version, whatever. May never know.
I compile mine on a Win7 x86. No longer has WinXP box.
Re: CommonControls (Replacement of the MS common controls)
I compiled on WinXP, and had no problems. I don't have VB6 on a non-XP computer, so I can't test after compiling under a different OS unfortunately.
Just thinking out loud here - I vaguely recall reading something about the length of a manifest needing to be a multiple of 4 bytes. Maybe this only holds true for certain OSes, and that's why we're seeing the discrepancy? For example, Krool's manifests are 5446 and 5711 bytes long, so if you add some space padding to the end to make them multiples of 4-bytes long, then try recompiling, it might make a difference (assuming Krool didn't already make the manifest lengths multiples of 4-bytes in the RES files)?
Kind of a shot in the dark, but maybe worth a try.
Re: CommonControls (Replacement of the MS common controls)
Here my two cents...
Good news:
- the regfree-approach works here (on a virginal Win 8 as well as on a Win 8.1 box) -
- found the cause for the error which prevented loading as a normal (registered) OCX into the IDE
..("Fehler beim Laden einer Dll" -> "Error whilst loading a Dll")
Will post the steps I undertook, which led to success with the regfree approach first -
then in another posting, what caused the Error with normal Loading of the OCX into the VB-IDE
Update: The instructions below (for regfree-usage ) refer to the latest version VBCCR10, which now
doesn't show the above Error: "Fehler beim Laden einer Dll" -> "Error whilst loading a Dll" ... anymore.
1) ... The approach below doesn't use the posted *.res Files, but works with the manifest-string directly:
.......(the latest one for VBCCR10, which Krool posted further below - here it comes again
3) To work around potential limitations of the VB6-Resource-Addin, I wrote a small Tool,
... which is able to apply Plain-Text-Manifest-Files directly into a given Binary. http://vbRichClient.com/Downloads/Manifester.zip
Just compile the small Manifester.exe from the contained sources - and after that
you can create a Link to it on your Desktop.
4) Unregister any other previous CCR-OCXes (in case you have any) on your machine -
... and then Register the correct one you downloaded under 2)
5) Open a VB6-IDE-StdExe-project - check-in the "Common Controls Replacment"-Component
... and drop a few of Krools Controls onto the Form - > compile the Project.
6) Close the IDE (any IDEs) which might reference a CCR-OCX.
7) Unregister the VBCCR10.OCX
8) DoubleClick (Start) your new compiled Executable which contains the few CCR-Controls.
... (this should fail now with "Component missing...", because the VBCCR10.OCX was unregistered)
... please make very sure at this point, that it does fail - otherwise the next steps will not make sense.
9) To make it work, place the compiled Executable in the same Folder as the (still unregistered) VBCCR10.OCX
10) Finally you only need to apply the Manifest-String-Content within your Executable (not the OCX)
... using the already mentioned Manifester-Tool under 3)... just drag&drop the Executable either
... onto the Manifester-Link on your Dektop - or directly onto the Manifester.exe.
... Now choose (I've already created a Textfile with the right content) the 'VBCCR10-regfree.manifest'
... which is already contained in the Manifester Zip (or -Folder)
... The Manifester-Tool will give you a message, when the attempt succeeded (or failed)
11) If the above step was successfully confirmed - then the right resource is now in your Executable
... DoubleClick it again - it should now run (remember, VBCCR10.OCX is still unregistered -
... you might check that from within a newly loaded VB6-IDE in the Components-Dialogue
12) To perform an opposite check, you can now remove the Manifest-Resource again from
... your Executable - drop it again on the Manifester, but cancel the File-Dialogue (choose no *.manifest).
... Then answer the MsgBox which asks you if you want to remove the resource, with "Yes".
13) If you now DoubleClick again, the good old "Component missing/not registered" message should pop up.
... (thereby proving, that there was no successful "Auto-Registering" involved, which is built-in into an
... upstarting VB-Executable when the matching OCX is sitting in the same Folder - though that mechanism
... worked only up to XP - and not anymore on Vista and greater...
Ok, hope these detailed steps work reliably also for others... as said, at least on two very new virginal
machines (8.0 and 8.1) it made no problems (didn't test on Win7 or XP).
Olaf
Last edited by Schmidt; Mar 10th, 2014 at 02:49 PM.
Reason: Updated to the new OCX-Version VBCCR10 + matching manifest
Re: CommonControls (Replacement of the MS common controls)
Ok, regarding the error which prevented loading as a normal (registered) OCX into the IDE
... throwing a message like: ("Fehler beim Laden einer Dll" -> "Error whilst loading a Dll").
This should be reproducable on any machine, when you ensure the following:
- There should be only one version of CCR32.ocx registered on your machine (in only one place
.. in the FileSystem
- Now try to find the matching CCR32.oca (if you have or find any, usually this is placed beside the *.ocx)
- Delete this typelib-cache (the *.oca-File) - and forget about it - it will be re-created automatically
- Finally (and that's the main-point) rename (temporarily) 'OLEGuids.tlb' (hopefully this is registered
. and sitting in only one single place in the FileSystem) ... e.g. to 'OLEGuids.tlb_'
Now (remember that the OCX is still registered, which normally should be the only necessity
for a successful loading into the IDE) - start a new IDE with an empty StdExe-Project and
try to Select the 'Common Controls Replacement' entry from the Component-Dialogue.
It should fail now.
So, that means that somewhere in the Public Interfaces of all the Public Classes or Public Ctls
(maybe even in the PropPage-Files, not sure) there's a Type exposed (in a Parameter, or a
Return-Value of a Public Procedure or Property or also in an Event) which doesn't belong there
(because it is defined in OLEGuids.tlb, which should be used only internally, in Modules,
Private- or Friend-Classes and not on the Public OCX-interface).
That's something of a task, to find this needle in the haystack - maybe Krool has a good idea
where to look first - or maybe some assistance from one of the better IDE-plugins (which should
be able to report, what type is used where) can shorten the time to find the culprit.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
I just say InstallShield (MSI) setup have problem installing COM components in Win8/8.1...
I was only trying to share my experience with you
Sorry, but the above statement doesn't contain much useful information...
(what issues exactly? ... and with all COM-compontens or only a few - or a single one mayhap?)
since you did mentioned you had problem installing (your own compiled of Krool's into OCX 6 about half a year ago and now) in Win8.
No, I didn't mention that - I've compiled Krools stuff into an OCX, to help Users in a german Forum.
And the issue was not an install-problem (the registering was successful in all cases) -
it was a Problem with loading the OCX from the Component-dialogue (or not correctly upstarting
*.vbp - which referenced the correctly registered version, but still were reporting the same error
as when trying to load the OCX directly from the IDE-Dialogue.
No installer, no installshield - heck I'm not even using Krools Tools at all personally.
Originally Posted by chosk
I am sorry that I even tried to share.
You shared only a blurry information about "mysterious-install-shield-issues" -
nothing to be sorry about.
Originally Posted by chosk
Blaming anyone (others or myself) for COM components not properly installed is no use.
Blaming will not make COM components install properly.
Now, that's not funny anymore - I've never talked about install-issues - or blamed anyone
about "improper COM-installations" - I was talking about people who (involuntarily perhaps)
disencourage COMponent-usage generally by promoting the "Everything in one Exe"-model.
What you wrote further above:
Originally Posted by chosk
...I would rather prefer it the way it is - just ctls and compiled into the same program exe.
Now I just copy the exe into any other Windows PC, even Win8, and it just run.
The VB6 runtime and other system required files are already pre-installed into Windows
and I can comfortably forget about the dreaded ActiveX/OCX registration in Win8
... had this tendency - and so I made my reply as a kind of counter-weight - and IIRC
I was not getting personally whilst doing so.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Schmidt
So, that means that somewhere in the Public Interfaces of all the Public Classes or Public Ctls
(maybe even in the PropPage-Files, not sure) there's a Type exposed (in a Parameter, or a
Return-Value of a Public Procedure or Property or also in an Event) which doesn't belong there
(because it is defined in OLEGuids.tlb, which should be used only internally, in Modules,
Private- or Friend-Classes and not on the Public OCX-interface).
The property "GetOLEInterface" in the RichTextBox control is referring OLEGuids.tlb.
I think that is the only "Public" contact with the OLEGuids typelib.
However, there is another problem I just encountered. When using the RichTextBox control from the CCR32.OCX then the .exe will crash during unload. ("MSFTEDIT.DLL access violation")
But this is only happening on WinXP. On Win7 it works...
The "Everything in one Exe"-model works the RichTextBox without any problem. WinXP and Win7.
Also the whole thing works up in W2K.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
The property "GetOLEInterface" in the RichTextBox control is referring OLEGuids.tlb.
I think that is the only "Public" contact with the OLEGuids typelib.
Then this needs to be wrapped up in a dedicated Class, and then this Class should be
exposed as the Return-Value (if there's still an interest in the OCX-version).
Originally Posted by Krool
However, there is another problem I just encountered. When using the RichTextBox control from the CCR32.OCX then the .exe will crash during unload. ("MSFTEDIT.DLL access violation")
But this is only happening on WinXP. On Win7 it works...
The "Everything in one Exe"-model works the RichTextBox without any problem. WinXP and Win7.
I'd not state it this way...
"Works without any problem" is too strong for my taste (when it's known to crash in the OCX-Variant)
"Works despite a problem which became apparent now" would be a better formulation.
Originally Posted by Krool
I am getting to dislike the .OCX experiment.
I wouldn't give up that fast - the regfree deployment-approach (and test) already worked out
quite well and is encouraging - now we only have to fix the RTBox-issues and find potential
other occurences of "exposed Typelib-Types".
Then a "Version 1" of the OCX could be made available (together with a matching manifest
for regfree deployment) ... and a release-cycle of "any half a year" or so could be introduced -
throwing out another filename for the OCX then, which includes the version-number (to not
collide with existing older binary versions of the OCX which could be met "out there in the wild"
(already working "well enough" for the purposes these older versions are used for in somebodys
application).
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
I hit a problem. I was testing my software on Win8 x64 and the TabStrip tabs appeared garbled. I could not see the tabs although I can use the arrow keys to switch from tabs to tabs.
Then I tried to simulate the problem using with a sample project with only the TabStrip and 12 tabs with images, like how mine look like. Because I have a lot of codes and also I use quite a lot of the controls, I actually put all your controls in the sample project although I only use the TabStrip and ImageList for the sample. I remember last week I tested my software with 6 tabs and images on Win8 x64 and there was no problem.
Re: CommonControls (Replacement of the MS common controls)
I just tested my software and the above sample on Win7 x64 and no problem.
It appears that the tabs are stacked one atop another vertically in Win8 x64. From the screen shot, starting from the bottom is the body of the TabStrip (white color) and then above it is the first tab also white color (with rect selected mark) stretched to full width. Then above it are the other 11 tabs.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
I remember last week I tested my software with 6 tabs and images on Win8 x64 and there was no problem.
So you are saying with 6 tabs it is working on Win8 x64 and with 12 tabs not?
Originally Posted by Krool
However, there is another problem I just encountered. When using the RichTextBox control from the CCR32.OCX then the .exe will crash during unload. ("MSFTEDIT.DLL access violation")
But this is only happening on WinXP. On Win7 it works...
I know now how to fix this problem.
Also I was able isolate the exposed OLEGuids places. (to solve the "Error whilst loading a Dll")
Originally Posted by Krool
I am getting to dislike the .OCX experiment.
I am now quite optimistic that soon there is a stable .OCX release.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
So you are saying with 6 tabs it is working on Win8 x64 and with 12 tabs not?
Yes. This is correct.
Update:
For the benefit of forum readers, Krool PMed me simple suggestion by adding 1 or 2 line of refresh in the ctl file to fix this problem. I tested as suggested and it works now in Win8 x64.
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
A question on ListView.
In visual-theme, when a ListView column is sorted, all the rows in that column will be "highlighted" in that the background for that all rows background in that column become light gray. Whereas the other columns/rows still show the alternate ledger colors.
I believe this is Windows default. Can a this be changed somehow?
In non visual-theme, that is in Win2000 style, the sorted column is not highlighted in light gray.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
Update:
For the benefit of forum readers, Krool PMed me simple suggestion by adding 1 or 2 line of refresh in the ctl file to fix this problem. I tested as suggested and it works now in Win8 x64.
In the next update I will publish the solution for everyone.
Re: CommonControls (Replacement of the MS common controls)
When I add an icon to CommandButtonW Picture and set PictureAndCaption to True, only the icon will appear not the text. Set Alignment to vbLeftAlign and pull the button longer the text won't show. Not sure what else I need to set.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
OK I get now.
I am aware you have a manifest in res for the compile exe so I compiled and run the exe and it works. Thanks.
And in case you want the "comctl32 version 6"-capabilities also in the IDE - you can use either a manifest
for VB6.exe (VB6.exe.manifest) ... already known I assume ... though the method which works by placing
the manifest-file in the same Folder was not working for me anymore for the VB6-IDE on Win8.
What *did* work on Win8 was beaming the manifest-infos directly into the VB6.exe-File - relatively easy
to accomplish, when you compile the Sources of the small Manifester.vbp-Tool I've posted a Link to recently.
Since the Programs-Folder has a quite tight security-behaviour - I've had to:
Make a Copy of VB6.exe into another Folder (I've placed the copy on my Desktop).
But from there one can drag the copy of the VB6.exe-File and drop it on Manifester.exe - or better:
a Link to Manifester.exe (I created a Link to it on my Desktop, along with regsvr32-Links for register
and unregsiter - all with Admin-rights-settings, earlier achieved over the Lnk-Context-Dialogue).
The dropping will cause an upcoming Dialogue -> choose the manifest-file: "CC6-minimalistic.manifest"
as the one to incorporate into the dropped VB6.exe-File.
Maybe rename the original VB6.exe in its Programs-SubFolder to 'VB6.exe.orig' to keep it "as it was" -
and then just move the "manifested" VB6.exe from your Desktop back into the \Programs\...\VB98-Folder.
That's it already - pretty styles shining up all over the place - Krools stuff working as it should -
and "world-peace-all-over" (Ok, until you open the ColorBox-Dropdown <g> - but Bonnie adressed
that already in a recent post here in this Thread).
To remove the manifest, either resort back from 'VB6.exe.orig' - or use the VB6.exe-file which
contains the manifest-resource - and follow the steps as described above again - only this
time do not choose any manifest-files - just cancel the up-popping dialogue...
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Schmidt
And in case you want the "comctl32 version 6"-capabilities also in the IDE - you can use either a manifest
for VB6.exe (VB6.exe.manifest) ... already known I assume ... though the method which works by placing
the manifest-file in the same Folder was not working for me anymore for the VB6-IDE on Win8.
...
...
Also doesn't work for me anymore in Win7 too. I used to do it in WinXP (I skipped Vista). That's why in the VB6-IDE, I am not seeing the pretty styles and have to compile every time to check the conversion I make.
I will give your advice a try later when I take a break. I am converting the labels, textbox, options, checks, buttons, combo and listbox.
Yes, Bonnie did address the color palette in an earlier post.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Schmidt
Since the Programs-Folder has a quite tight security-behaviour - I've had to:
Just install it into another folder other than 'Program Files', i even have a folder names 'Program Files (no nagging)' LOL.. Looks like a program files folder but works without all the stupid moronic behaviour of the 'Program Files' folder which was introduced with Vista.. I still never understood why MS changed it, as it was the one of those stupid decisions they made as it's so easily circumvented by just not installing in that folder...
Re: CommonControls (Replacement of the MS common controls)
There is this question on my mind for the last few weeks and I am not really at ease if I don't know what I should do. So I will try and ask.
For about 9 years, I have been using the following codes in my VB6 projects so that the controls get the sexy XP-theme look. As you are all aware, this sexy visual-theme continues into Vista, Win7 and now Win8. No doubt will still do for future version of Windows.
Private Type tagInitCommonControlsEx
lngSize As Long
lngICC As Long
End Type
Private Declare Function InitCommonControlsEx Lib "comctl32.dll" _
(iccex As tagInitCommonControlsEx) As Boolean
Private Const ICC_USEREX_CLASSES = &H200
Public Function InitCommonControlsVB() As Boolean
On Error Resume Next
Dim iccex As tagInitCommonControlsEx
' Ensure CC available:
With iccex
.lngSize = LenB(iccex)
.lngICC = ICC_USEREX_CLASSES
End With
InitCommonControlsEx iccex
InitCommonControlsVB = (Err.Number = 0)
On Error Goto 0
End Function
Private Declare Sub InitCommonControls Lib "comctl32.dll" ()
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" ( _
ByVal lpLibFileName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32" ( _
ByVal hLibModule As Long) As Long
Private m_hMod As Long
Private Sub Form_Initialize()
m_hMod = LoadLibrary("shell32.dll")
InitCommonControls
End Sub
Private Sub Form_Unload(Cancel As Integer)
FreeLibrary m_hMod
End Sub
So far, I have been using these codes with the comctl32.ocx and of course linked to comctl32.dll and there been no problem. Linked and no crash on exit. The questions I like to ask are:
1) With the all-in-one exe, are the codes still needed.
2) Any harm if I just leave them in there as they are?
3) Or I should remove them?
Note: I know there is a "SetupVisualStyles Me" in the Form_Load of all forms. Is it doing the same purpose? I look at it may not be but of course I am not sure.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
1) Ensure your application link to Comctl32.dll
The equivalent in the "all-in-one" exe are the functions "InitVisualStyles" and "SetupVisualStyles".
The "SetupVisualStyles" also fixes some issues. Details can be found here.
Originally Posted by chosk
2) Preventing crashes at shutdown
The code "LoadLibrary("shell32.dll")" is only necessary when a custom UserControl is involved in the Std-EXE.
All my Common Controls are loading this library also. See the functions "ComCtlsLoadShellMod" and "ComCtlsReleaseShellMod".
Originally Posted by chosk
1) With the all-in-one exe, are the codes still needed.
2) Any harm if I just leave them in there as they are?
3) Or I should remove them?
There should be no harm when you keep yours also.
You can replace yours with the "InitVisualStyles" and "SetupVisualStyles" functions as because of the "fixes".
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
Thanks for your explanation.
I have converted all the controls over to your all-in-one controls. Conversion also include those basic controls like CommandButton, CheckBox, OptionButton, Frame, Label, TextBox. Those in comctl32.ocx and comct232.ocx were the first to be converted earlier. The only ones I cannot convert and there is actually no need to are the PictureBox and Image.
I have seen the functions you mentioned and I will now remove the codes I have been using since they no longer serve any purpose.
Re: CommonControls (Replacement of the MS common controls)
Here is an update to the complied res problem I had in post #241 where I always encountered "Invalid XML Syntax" error on the 2nd last line of the manifest file: http://www.vbforums.com/showthread.p...=1#post4626989
This means that I will have to re-compile the existing res file. This pose a problem since I am now always getting the "Invalid XML Syntax" every time I compile a res file. So, I did searches over the weekend on my res problem on the Internet but all in vain. The common search result was missing a Visual C++ file. Tried installing from MS website the 2005 and 2008 version no use.
Then I started looking at the manifest and the the compiled res file sizes. Up to now I am using a res compiled by rc.exe some years ago. If I were to compile again now and use it, I will get the Invalid XML syntax error. So I check the size of the old and new compiled res files. The old file is 788 bytes and new one is 792 bytes. The strange thing is both are compiled from the same unchanged manifest file so how can there be this difference. My conclusion is somehow something is padding that extra 4 bytes and this triggered the Invalid XML syntax.
So I experimented with the manifest file. I removed all formatting and put them into 5 lines each begining and ending with respective tags in one line. I make sure the manifest file size is divisible by 4 exactly. Example below, some items removed and "and ending with" added for clarity:
// Icons for this application
AAA ICON MOVEABLE PRELOAD MyProg.ico
Compiled and viola success! Sexy theme and proper "bigger" 32x32 icon in the Windows task bar, not the upscale from 16x16 pixelated one.
ps: I know this is not the proper place/thread but on a by-the-way-basic, may I like to ask for confirmation from experts here whether what I done to the rc script to include icon is it the correct and proper way. Although it runs as I wanted it to, it is always better to get this vetted so that neither myself or anyone who use this will not get an expected surprise.
Last edited by chosk; Mar 10th, 2014 at 09:44 AM.
Reason: Edited para 3 to make clearer.
Re: CommonControls (Replacement of the MS common controls)
Are you sure the problem isn't with the older RC.exe maybe not supporting 32-bit icons? try loading a 32bit icon as a form icon and you also get an error in VB. Just like the later windows don't support the older iconlibraries anymore (which really is a stupid thing)..
Re: CommonControls (Replacement of the MS common controls)
The problem (Invalid XML syntax error) is not due to the older RC.exe although I am using the same older RC.exe that came with VB6 before and now. I use the same RC.exe to compile the re-edited rc script and resultant res now works.
The 32-bit icon is a new thing I tried now and not related to the Invalid XML syntax error. By the way, this "proper icon" trick in fact does wonder to the "professional look" of VB6 apps. I just realised that the icon at the bottom left of the Windows Explorer in Win7 shows the 48x48 icon. Previously it was the ugly pixelated upsize of the 16x16 icon.