Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Shell32 XP vs Win7 1

Status
Not open for further replies.

waytech2003

Programmer
Jul 14, 2003
316
US
In many of my programs, created on an XP SP3 computer using VB6 SP6, I have used "Windows Shell Controls and Automation" to get certain information as seen below.

Code:
Private Sub Form_Load()
With New Shell32.Shell
   MsgBox .NameSpace(ssfCOMMONAPPDATA).Self.Path
End With
End Sub

When compiled on the XP system, the programs will run on ME, XP, and Win7. If compiled on the Win7 system, they will not run on ME, or XP. I get an error "Runtime Error 430, Class does not support automation or does not support expected interface"

Is there a way to fix this?
 
Have you tried a CreateObject approach. I have an inkling that use of New may be 'binding' you to the version of Shell32.Shell present at compile time.
 
Hugh

No I have not, and do not know how.

Can you give a quick example on how thats done?
 
As pasted into a test project from this forum some time ago;

Public Function GetSpecialPath(vDir As Variant) As String
'ref ' vDir can be either one of the ShellSpecialFolder constants (start with ssf) if you have set a reference to Microsoft Shell Controls and Automation Alternatively it can be a normal path string, or a shell folder object
GetSpecialPath = CreateObject("shell.application").NameSpace(vDir).Self.Path
End Function
 
Good one.
Some research regarding the merits of early and late binding is recommended.
 
That provides a detour, but does it get at the real problem?

I don't develop on Windows 7, but having looked through shell32.dll a bit on Windows 7 (RC) using OleView I haven't seen any changes in classids. I have not checked exhaustively, but I see nothing that breaks binary compatibility.

Furthermore I don't see anyone posting questions about the problem described in this thread. I can't claim an exhaustive search but I dug pretty deeply.


When you're under the gun any solution is welcome, but I suspect there is a deeper problem. Perhaps there is something wrong with the way waytech2003 is compiling VB6 or with his installation of the VB6 development tools.

If somebody can shed more light on any compatibility issues with shell32.dll in Windows 7 I'd like to hear about it. I'd almost bet this was actually Win7-64 and VB6 is not properly installed or being run correctly there.

There are no guarantees about using VB6 on Win7. But unless SP6 installed successfully and you run the IDE elevated many odd things may occur. That much is clear from the experiences people have had.
 
Dilettante

This is on Win7-32bit Pro. I too would like to know if anyone else could repeat this problem on a test setup.
 
Knowing it isn't a 64-bit problem helps some. More info would be great, I agree.
 
I have recently come across this exact same issue. Would CreateObject work in my situation as well? Are there any problems with using this code on older systems such as XP or Server 2003?

Code:
With New Shell32.Shell
   Set myFolder = .BrowseForFolder(frmForm.hwnd, pTitle, BIF_Flags, strRoot)
End With

If at first you don't succeed, then sky diving wasn't meant for you!
 
I think it would help.


I just compiled and tested a program on Vista. Then I took the EXE to an XP SP3 VM and it fails there. So this wasn't a Windows 7 problem at all, but a problem with Windows 6.x in all forms (including 2008 Server).

A number of these system components seem to break binary compatibility between Windows versions. I can't find anything documenting this though, but since Microsoft is ignoring VB6 now that's no surprise.

A C++ program would probably call the Shell API and bypass the COM interfaces. A VBScript would have to use late binding. Thus Microsoft feels no pain.


Late binding is no real penalty here anyway. Most of the things you'd do via Shell32.dll are low volume activities, almost never in a tight loop. So the performance penalty should be minimal.

This is still quite disconcerting.
 
Thanks for your response (and testing) dilettante.

If at first you don't succeed, then sky diving wasn't meant for you!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top