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 bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ShellExecute Solution For You!! 2

Status
Not open for further replies.

MrVB50au

Programmer
Mar 16, 2003
326
AU
'***************************************************************
'After a long pain staking programming experience trying to find
'What really works and getting information from FORUMS, download
'sample pages etc,. I have finally put everything together and
'came up with the altermate solution to my hunt for a command
'that allows me to edit a pic of the common kind with no hassle.
'
'The commonly used "ShellExecute" function can be Public in a
'module or Private for localization. You choose what's better.
'***************************************************************
'

Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long


Sub OpenPicEditor()
'**********************************************************
'This procedure is heavily commented for your understanding
'and pleasure. Hope this clears up many queries on Me.hWnd
'and that you can keep working to get your app' under way.
'
'Email datasoftwaredevelopment@hotmai.com if you have any
'questions regarding this code and I will try and help.
'**********************************************************
'
'Declare variables for file path
'and execution.

Dim GetIt As Long
Dim
sFile As String.
'
'If you have a variable that stores the path
'you simply replace "C:\Program Files\Image.bmp"
'with that variable.

sFile = "C:\Program Files\Image.bmp"
'
'Check and see if "sFile" is not empty,
'and if it's not then continue.

If Len(sFile) > 0 Then
'
'Now this section had been disputed, "Me.hWnd" was told
'to many that it was to be removed..NO..It stays.

GetIt = ShellExecute(Me.hWnd, "Open", sFile, &H0&, &H0&, 3)
End If 'End of IF Statement.
'
'Everything is working just fine and I also checked memory
'in My Computer and is working fine. No TSR's.

End Sub
 
That's good information. You should post it as a FAQ so it will be easier for others to find in the future.

You've earned a star. Thanks and Good Luck!

zemp
 
Thank you Zemp
 
I just tried this code on my computer running Windows XP.
Instead of opening the bitmap in Picture Editor (MS Paint) it opened the bitmap in Windows Picture and Fax Viewer which is the default picture viewer in Windows XP.
I had to change the lpOperation parameter from "Open" to "Edit" to fix this problem.
 
So when you changed the "Open" to "Edit" this took you to MSPaint?

 
Yes!
 
Well, I'm running Win98 and open took me straight to the default editor.

So, inasmuch as to solve this problem for Win98 and WinXP what would you suggest?

And, what if someone else has a different operation than these?
Do we then have a popup box to allow users to choose which program they'll like to use to edit the picture? being: MS Paint, or whatever?

I think really it's up to the user to choose before installing a graphics editor or viewer of what files they wish to associate the newly installed graphics program.

I used the "Edit" command and got nothing.

So, what would you suggest?
 
OK, Here's what happens:

1. Every PC is different.
2. Every Association to files is up to the user.
3. Microsoft doesn't know if you chose MS Paint
or PhotoShop Pro to associate your files.


What it all boils down to is the user associating their files correctly. If they associate (eg: bmp files to a viewer) then so be it. To edit files they need to either open their editor and do it there. Or, disassociate the bmp files from their viewer (like I have just done) and reassociate them accordingly (like I have done).

If you need further assistance please feel free to ask and I'll try and help.

Andrew G.
Developer.
DataSoftware Development[TM]
Website: UNDER CONSTRUCTION.
******************************
 
In fact the lpOperation parameter plays an important role in the operation of ShellExecute function. When you right click a file icon in Windows Explorer, you see several Verbs in the context menu that Windows can execute on that file.

In windows 98 the default verb for bitmap files is Open which opens the file in MS Paint. Windows 98 does not expose an Edit verb that is why it fails on your computer running Windows 98.

On the other hand the default verb in WinXP for bitmap files is to view the file in Picture viewer. So when your code runs on WinXP, the picture viewer is called up.
However, in WinXP the verb associated to edit the file in MS Paint is Edit which opens the picture for editing.

If you have installed a custom program for picture editing for example PaintShop Pro or Adobe Photoshop etc, your bitmap files are more likely to be associated to these applications for viewing/editing. In this case your code will fail to run MS Paint even on Windows 98, instead the currently "associated" program will be started.

If you want to edit your bitmap file in MS Paint, no matter what is the OS or what program is associated with your picture files, it is advised to open that bitmap explicitly with MS Paint - this is very simple.

'----------------------------
'
Dim MyFile As String
MyFile = "D:\Winnt\Mandelbrot.bmp"
Shell "mspaint.exe """ & MyFile & """", vbNormalFocus
'
'----------------------------

Here, we get the advantage that the actual path of mspaint.exe is always known to Windows and we do not need to tell where it resides. Windows finds the file itself.
 
OK, I will try this, thanks!!
 
OK, here's the result:

Runtime Error '53'

File not found:

yet, when debugging the path is in the string variable.

Shell "mspaint.exe """ & MyFile & """", vbNormalFocus

 
There's always another way around this, and that's to create my own bmp editor so it just simply stays in the application huh?

 
Or, Simply repost the code and add that this is only for Win98 OS's HUH?
 
After reading your second last post, I rebooted my machine from Windows 98 and tested the code.

Unfortunately I got the same error. FNF :(
Then I changed the shell command to:

Shell "pbrush.exe """ & MyFile & """", vbNormalFocus

It succeeded.

If fact the pbrush.exe file is located in Windows directory (Win98) and mspaint.exe is located in \Program Files\Accessories directory, which is not known to Windows.
Thats why pbrush succeeded.

Then I searched my Winnt folder for pbrush.exe and found that it does not contain such file. Not even anywhere in Program Files folder. It only contains mspaint.exe in System32 folder which Winnt finds and executes.

This discrepency seems to be annoying. It means that mspaint will only work on WinXP and pbrush on Win98.
We are still at the same point where the discussion began. I think the idea to write an editor of your own is nice. :) This will bring you out of this dilemma between mspaint and pbrush, or perhaps Win98 and WinXP.

Good Luck!
 
No, I have found a solution.

Try this.


Create a new Form1

Add a prompt to the user.

Add two command1 buttons

One with Window98
Other WindowsXP

Then add the execution to each but with a difference.
the Win98 button has the "Open" command.
the WinXP button has the "Edit" command.

if the user clicks on the appropiate one then it will open.

Try IT! It works

email me if you wish at: datasoftwaredevelopment@hotmail.com

Andrew G.
 
Yes, I believe that this will work. But I am not going to test it right now. Otherwise I will need to restart my machine once again in Windows XP to try the "Other WindowsXP" button.
 
There is also another solution to this problem and that's to create a simple little database with the table name of Application, then, creating a field name Called EditOpen.

In the EditOpen field place the word Edit or Open. When the user first goes to open the picture, have them verify which OS they are using. This only needs to be done once and only once. I had placed a menu option that also allows the user to change that option if they ever need to. So, it makes good sence to allow these things to happen.

If you hadn't told me about it, I guess I wouldn't have known. Are there other things you think I should concider when programming?

Is WindowsXP so different that even commands as simple as the one we came across can either break or make an application?

Please do tell!


Andrew G.
Product Manager and Developer
DATASOFTWARE DEVELOPMENT

 
I started development in VB on Win98 platform. I used Win98 for more than four years. After that I also started using Windows 2000 and Windows XP.

When I tried to run my programs on these systems. I found that there are many which simple don't run on WinXP. The reason was, I usually make heavy use of Win32 APIs in my programs and those APIs which I used with Win98 were not compatible with WinXP. The API Viewer of Visual Basic contains declarations for ANSI version of functions where as WinXP requires Unicode version.

This incompatibility between ANSI and Unicode is the major source of failure of Win98 programs on WinXP.

To rectify this problem I had to declare both the ANSI and Wide versions of a function in my program. Detect the OS and call the right function which is supposed to be supported by the current OS.

Here is an example of GetOpenFileName function declaration in VB API Viewer:

Code:
Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long

This function works fine on Win98 but simply fails (atleast as I experienced) on WinXP. To make it work on WinXP I had to change "A" to "W" - Here is the WinXP version.

Code:
Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameW" (pOpenfilename As OPENFILENAME) As Long

This worked on WinXP but not on Win98.

To make this work on both systems I had to declare both these fuctions and use the appropriate one based on the current OS.

Code:
Declare Function GetOpenFileNameA Lib "comdlg32.dll" (pOpenfilename As OPENFILENAME) As Long

Declare Function GetOpenFileNameW Lib "comdlg32.dll" (pOpenfilename As OPENFILENAME) As Long

Moreover, if I used Unicode versions, I also had to convert string variables to and from unicode using StrConv() before and after calling the API function respectively.

In the end, I would say that writing a Visual Basic application that works equally both on 98 and XP is a tricky job which requires these considerations, particularly if you rely much on Win32 APIs as I do.

Due to these experiences, I always test my applications on both of these platforms and perhaps it is one of the major reasons I always have a dual boot system on my PC running Win98 and WinXP or 2000.

-----------------------------------------------------------

Finally, I would suggest solution to our original problem.

'----------------------------------------------------------
'
Dim MyFile As String
MyFile = "D:\Winnt\Mandelbrot.bmp"
On Error Resume Next
Shell "mspaint.exe """ & MyFile & """", vbNormalFocus
If Err = 53 Then 'mspaint not found. Try using pbrush
Shell "pbrush.exe """ & MyFile & """", vbNormalFocus
End If
On Error Goto 0

'
'----------------------------------------------------------
 
Yep, that did the trick...

Now, what if, I didn't want to use the API, since this is the first time I ever had to use it?

Could I use something else rather than the API?

AndrewG.
 
If you don't want to use APIs then you have to use ActiveX controls.

They are simpler to use but increase the dependency of your project on other files. This results in more overhead to your program and the size of your installation package grows.
For example if you do not use GetOpenFileName API then you have to use Microsoft Common Dialog Control.
A program containing API calls will run on a fresh Windows 98 or Me without requiring VB whereas one that uses ActiveX controls will not run on Windows 98 because Win98 does not contain ActiveX controls. They are installed with Visual Basic.

However, I will not suggest, or recommend whether to use Win32 API or ActiveX controls. Although ActiveX controls are very simple and easy to master but they have their own disadvantages. Both have their pros and cons and the choice is solely yours.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top