We have places in our application that open up graphics files in Paint. All our programs use Utility( 'RUNWIN', 'PBRUSH somepath' ) to do this, but this isn't working in Win2000. Instead, Utility( 'RUNWIN', 'MSPAINT somepath' ) DOES work, but we tested this on WIN98 and it didn't work there. It seems like PBRUSH works on versions of Windows before 2000, but not MSPAINT but MSPAINT works on Win2000 but not on earlier versions.

Is there any way we can open our graphics files with one command that will work for all operating systems? If not, is there some other way we can work around this problem?

Check out this thread http://www.revelation.com/WEBSITE/DISCUSS.NSF/09d90959a1a106db8525652c0042cb86/33785990A7639A9385256AE70024C023?OpenDocument

Bottom line - you'll never know what is loaded on a user's PC, pbrush, mspaint, whatever.

Is the requirement to edit images or merely display them?

The Sprezzatura Group

World Leaders in all things RevSoft

We want them to be able to edit. In fact, we've been sending more than just BMPs to Paint, we've been sending things like JPGs to it, too, whihc Paint has no problem opening and editing. I followed the thread that Paul Rule gave me, but that will only open whatever application is associated with the extension. So if a user has .jpg associated with IE and we want to open it up in Paint so they can edit it, OpenDocs() would open it up in IE. So, the question is, is there some way to open up graphics files with a variety of extensions in Paint so they can be edited that will work in both Win 2000 and other versions of Windows?

Another thing that occurred to us is that if we could check to see what operating system we're in we could call PBRUSH or MSPAINT conditionally. Is there some way we can figure out what operating system OI is running on?

If you really must know which version of the operating system you are operating under, then you can access it using the SYSTEM VERSION property (albeit in a somewhat cryptic form) or our Utility 32 Product.

The Sprezzatura Group

World Leaders in all things RevSoft

I tried the VERSION property, but it just gave me 3.95 for both Win2000 and Win98. How can I use this decide whether to use Utility( 'RUNWIN', "PBRUSH…" ) versus Utility( 'RUNWIN', "MSPAINT…" )?

I think I came up with a solution on my own, but I need some feedback from all of you before I'll know whether it will work 100% of the time. I noticed that the return value of Utility('RUNWIN'…) is an @FM array that contains the instance handle, the module handle and the task handle in , and respectively. I noticed that when I make a call that doesn't work, like PBRUSH in Win2000, these will all be very low numbers, like 2, 0 and 0, but when I get a successful call, these are very high numbers, like 9286, 8847, 9103, but that these change each time. I came up with the following bit of code, but I don't know enough about how the handles get assigned to know if it will work. It is:

Return=Utility( 'RUNWIN', "PBRUSH C:\mybitmap.bmp" )

Test=( Return + Return + Return ) / 3 ;* Gets the average.

* If successful, these will probably all be really big numbers.

if Test ⇐ 10 ;* 10 is an arbitrary small number.

• PBRUSH didn't work, so use MSPAINT, instead.

  Return=Utility( 'RUNWIN', "MSPAINT C:\mybitmap.bmp" )

end

What I do, is get the average of the handles and if that value is lower than a certain arbitrary amount (I used 10), I assume that Utility() failed and try it the other way.

I realize this is crude, but will it work?

See if the below helps; if you have not already seen this.

All -

                  This topic relates to the previous discussions of various problems launching documents in Windows

                  95/98, and Windows NT. One problem was related to documents whose associated executable

                  was registered with a directory containing spaces, such as:

                  c:\Program Files\Microsoft Office\Office\WinWord.exe

                  To open a document with the extension .DOC, the Windows API incorrectly reports that the

                  program to run is:

                  c:\Program

                  (Microsoft documented this problem with Windows 95 and it still exists in Windows 98.)

                  One work-around was to modify the registry settings (per workstation) so that the path would read:

                  c:\progra~1\micros~3\office\winword.exe

                  This is difficult to fix on each workstation, since the path might be \micros~1\ or \micros~3\ or

                  whatever depending on the order various programs were installed.

                  While experimenting with this problem, the following potential fix was found. However, we are not

                  certain that it will work on all the supported OS's, and would appreciate some feed-back:

                  1. Create a SYSPROCS/DLL_SHELL record:

                  SHELL

                  SHORT PASCAL ShellExecute(USHORT, LPVOID, LPCHAR, LPVOID, LPCHAR,

                  USHORT)

                  2. Create a test program called OpenDoc:

                  function OpenDoc(Name)

                  declare function ShellExecute, IsEventContext, Get_Property

                  if IsEventContext() then

                    Parent=@window

                    Frame =Get_Property(Parent, "MDIFRAME")

                    if len(Frame) then

                      Parent=Frame

                    end

                    hwnd=Get_Property(Parent, "HANDLE")

                  end else

                    hwnd=0

                  end

                  return ShellExecute(hwnd, 0, Name: \00\, 0, drive(): \00\, 1)

                  Instead of using Utility("RUNWIN"), use the OpenDoc function, passing the name of the document

                  (example, "OILOGIN.BMP" or "README.WRI").

                  If we can determine that this works on all the supported OS's, we can build the logic into

                  Utility("RUNWIN").

                  Thank you,

                  Cameron Purdy

                  Revelation Software

                  Compose a Response to this document or a new Main Topic

                  Launching Documents (Cameron Purdy) You are here 

                  . . Re: Launching Documents (David Pociu)

                  . . . . Re: Launching Documents (Cameron Purdy)

Hope it helped

JoeD

View this thread on the forum...