How to load system info in vista?

TristanFord

New member
Joined
Dec 25, 2008
Messages
3
Programming Experience
3-5
Hi,

I am trying to load the "system info" dialogue.
Right Click My computer Properties.

In windows XP i use the following code. It works fine.


Shell("rundll32.exe shell32.dll,Control_RunDLL sysdm.cpl", AppWinStyle.NormalFocus, False, 0)


In vista it does not.
That particular control panel item it loads is not the same window as in vista.
Right Click my computer properties. It brings up a system info dialogue.
With system, user/os/system support info.

Any help with this would be much appreciated.

Cheers
Tristan F
 
I found a sample app on planet source code. Which was verry usefull.

Shell("control.exe /name Microsoft.System", AppWinStyle.NormalFocus, False, 0)

Whats interesting here is that ounce again microsoft decided to change what was going on in the OS and instead of referencing rundll and the contorl panel.
The control panel is actually control.exe

Just go start run > control.exe
:)

Cheers
Tristan
 
Shell is a Runtime function held over from VB6 for backward compatibility. The Process class is a member of a System namespace so it has been designed specifically for .NET code rather than to behave the same as a VB6 function.
 
Shell is a Runtime function held over from VB6 for backward compatibility. The Process class is a member of a System namespace so it has been designed specifically for .NET code rather than to behave the same as a VB6 function.
While I agree with what you mean, I think it is correct to distinguish the terms and reasons for usage here. Shell is a Runtime function from Microsoft.VisualBasic assembly, and Runtime methods do have a VB6 legacy and methodology, but they are not designed for backwards compatibility, they are designed for helping VB users both new and old do easy tasks, same as the new My feature from same assembly. Compatibility functionality can be found in namespace/assembly Microsoft.VisualBasic.Compatibility, which should not be used in new code. Visual Basic documentation (Visual Basic Programming Guide, Visual Basic Coding Conventions) encourage use of Runtime functionality, but many multi-lingual .Net users as you contradicts this, likely to encourage better usage of the language independent .Net library, both for easier transition between languages and to produce better OOP code. So I agree with your statement apart from Runtime existing only for compatibility. It is a "I (don't) recommend" rather than "Don't use" IMO.
 
While I agree with what you mean, I think it is correct to distinguish the terms and reasons for usage here. Shell is a Runtime function from Microsoft.VisualBasic assembly, and Runtime methods do have a VB6 legacy and methodology, but they are not designed for backwards compatibility, they are designed for helping VB users both new and old do easy tasks, same as the new My feature from same assembly. Compatibility functionality can be found in namespace/assembly Microsoft.VisualBasic.Compatibility, which should not be used in new code. Visual Basic documentation (Visual Basic Programming Guide, Visual Basic Coding Conventions) encourage use of Runtime functionality, but many multi-lingual .Net users as you contradicts this, likely to encourage better usage of the language independent .Net library, both for easier transition between languages and to produce better OOP code. So I agree with your statement apart from Runtime existing only for compatibility. It is a "I recommend" rather than "Don't use" IMO.
I certainly see that point of view but I disagree because I don't believe that all those "VB6" functions were added to make it easier for new programmers. They were implemented to behave exactly as they did in VB6 to make VB6 developers whine less about switching to VB.NET. Given that MessageBox.Show already existed, how does MsgBox make life easier other than to allow VB6 developers to write VB.NET code that looks more like VB6? If they'd left out useless functions then I might have believed that they were trying to make VB.NET easier in general but, as they didn't, I can only conclude that it was done specifically for VB6 developers. Shell is another example of a useless function because, as far as I'm aware, it offers no advantage over Process.Start.

I don't discourage use of Runtime functions where they add value (they are just functions, after all) but those situations are few and far between. Most Runtime function usage is simply because VB6 developers write the code and they don't care to change or new developers have learned from VB6 developers and don't know the difference.

Having said all that, I could be completely wrong.
 
Back
Top