Toggle between SP1 and SP2

[Lucvdv]

For the TIPS section:

Some time ago, there was a discussion about installing SP1 and SP2 side by
side and toggling between them for different projects.
( Message-ID: <#[email protected]> )

I just created something that may be useful to those who installed it that
way.

I've always had shortcuts to TD, component designer and the component
database manager on my quick launch bar. Today I added a fourth icon that
displays which service pack version is current, and flips to the other when
clicked.

Behind it is a small VB6 app, of which you find the source below.


The shortcut icon is either the "R1" or "R2" icon from moricons.dll and
must be preset to one of those when the shortcut is created.
Moricons.dll is normally present in the system32 folder by default.

The icon indexes in the file are 82 and 83 on XP Pro, on Win2000 you may
have to change the VB source a little if they happen to be different.


The actual switching from one SP to the other is done by two .cmd files (I
already had those and didn't modify them, just call them from the VB app).

The .cmd files follow first.
"|" indicates start of a line, if your newsreader breaks a line in
mid-command it won't be there so you know it's a continuation of the
previous line.

This is the file that switches to SP1, for the other one just replace SP1
by SP2 in the paths. You'll probably have to adjust them to where you
installed the repositories on your system anyhow.

On my system, the SP1 database and repositories are installed in D:\Windows
Embedded\XPeSP1\ and SP2 in D:\Windows Embedded\XPeSP2\.

"osql" is osql.exe in the SQL Server binn folder, add it to your path if
necessary (I think it's there by default, but I'm not certain).

| osql -E -Q "sp_detach_db 'MantisSQLDB'"
| net share Repositories /DELETE
| net share Repositories="D:\Windows Embedded Data\XPeSP1\Repositories"
| osql -E -Q "sp_attach_db 'MantisSQLDB', 'D:\Windows Embedded Data\XPeSP1\MantisSQLDB_Data.mdf', 'D:\Windows Embedded Data\XPeSP1\MantisSQLDB_Log.ldf'"
| pause


Now the VB app.
Create a new standard application, remove Form1 from the workspace and add
a standard module instead, make sure the entry point in project properties
is "Sub Main", add "Microsoft Shell Controls and Automation" to the project
references, and paste the code below into the module.

You'll have to adjust the line with the path to the Quick Launch toolbar
folder so it matches your system.

It alse expects two .cmd files called "XPeSP1.cmd" and "XPeSP2.cmd" in its
own folder or accessible through the path.

When the application is compiled, create a shortcut called "ToggleSP" to it
in the quick launch toolbar (make sure it has no extension in explorer: the
filename in a DIR command in a cmd window should be "ToggleSP.lnk").


Sub Main()
Dim sh As Shell32.Shell
Dim sc As Shell32.ShellLinkObject
Dim fo As Folder
Dim fi As FolderItem
Dim IconIndex As Long, IconPath As String

Set sh = CreateObject("Shell.Application")

' Next line broken by newsreader
Set fo = sh.NameSpace("C:\Documents and Settings\lucvdv\Application
Data\Microsoft\Internet Explorer\Quick Launch")
' The lines above are one statement

For Each fi In fo.Items
If fi.Name = "ToggleSP" And fi.IsLink Then Exit For
Next

If Not fi Is Nothing Then
Set sc = fi.GetLink
IconIndex = sc.GetIconLocation(IconPath)
Select Case IconIndex
Case 82
sc.SetIconLocation IconPath, 83
sc.Save
Shell "XPeSP2.cmd", vbNormalFocus
Case 83
sc.SetIconLocation IconPath, 82
sc.Save
Shell "XPeSP1.cmd", vbNormalFocus
End Select
End If
End Sub



BTW: I tried turning it into a .vbs script instead of a compiled
application, but it seems that sc.GetIconLocation doesn't work in a script
(it gives a Type Mismatch error).

 

[Slobodan Brcin \(eMVP\)]

Hi Lucvdv,

Thanks for providing more info and sample to the community.

Regards and Happy holidays,
Slobodan

 

[KM]

Lucvdv,

Nice code. Will save someone hours of thinking whether to have only SP1, only SP2 or both together

KM

PS. Minor suggestion to make the code less directory setup specific: Instead of hardcoded "C:\Documents and
Settings\lucvdv\Application Data" you can use an enviroment var like APPDATA. IIRC, ssfAPPDATA of ShellSpecialFolderConstants.

 

[Lucvdv]

PS. Minor suggestion to make the code less directory setup specific: Instead of hardcoded "C:\Documents and
Settings\lucvdv\Application Data" you can use an enviroment var like APPDATA. IIRC, ssfAPPDATA of ShellSpecialFolderConstants.

You're right, but I just posted the code as I wrote it for myself, and I
didn't expect to ever install it in another directory.

If I had made it configurable, I'd probably have used registry settings.
I wrote a DLL long ago that can be called from VB6 to get easy access to
all registry keys, I use it in almost every VB program.

 

[KM]

Lucvdv,

From the info you provided I suspect you are using VB 6.0 (not VB .Net).
In .Net version you get the registry access "for free" (Microsoft.Win32.Registry/Microsoft.Win32.RegistryKey)

Anyway.. Even with 6.0 you get beautiful WScript.Shell to expand any environment variable (WScript.Shell.Environment("var_name"))
or, even better, WshSpecialFolders object.
The RegRead and RegWrite methods of the WScript.Shell will give you simple way to access the registry.

Although, I like to use these object from JS/VBS (not from VB).

Well... using different objects is just a matter of taste. I prefer C++ and Win32 API anyway

 

[Lucvdv]

Lucvdv,

From the info you provided I suspect you are using VB 6.0 (not VB .Net).
In .Net version you get the registry access "for free" (Microsoft.Win32.Registry/Microsoft.Win32.RegistryKey)

I often use VB6 where you would normally use scripting or a batch file: the
intellisense is a beautiful invention, and being able to single-step
through a program often saves some debugging time too.

I prefer VB6 over .Net because of the flexibility during debugging (if
there's anything that should be added to VB.Net very urgently, it's edit &
continue the VB6 way).

I use VB.Net and VC++(6 and .Net) too, but only for "real projects".

Anyway.. Even with 6.0 you get beautiful WScript.Shell to expand any environment variable (WScript.Shell.Environment("var_name"))
or, even better, WshSpecialFolders object.
The RegRead and RegWrite methods of the WScript.Shell will give you simple way to access the registry.

All of which didn't exist yet when I wrote the first version of my DLL
That was way back in the NT4 days, before IE4 came out.

I'm still using it today because it offers some more flexibility in
accessing the registry (choice between name-based or handle-based key
access, enumeration of subkey or value names into a string array, etc.)

The only drawback is that it supports only REG_SZ and REG_DWORD, but that's
enough for 95% of applications.