Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 30 MAY 1998 05:55:36PM Dsig (SigSolutions) wrote:

Once again .. I am looking to see if there will be a fix for what seems to be a problem with UTILITY and launching some 'documents' in Windows (win95).

If the question was answered (when it will be fixed) i appologize for having missed it ..

dsig

David Tod Sigafoos ~ SigSOlutions

dsig@teleport.com cis:70302,77 voice:503-639-8080


At 02 JUN 1998 10:30AM DSig (SigSolutions) wrote:

Once again .. I am looking to see if there will be a fix for what seems to be a problem with UTILITY and launching some 'documents' in Windows (win95).

If the question was answered (when it will be fixed) i appologize for having missed it .. but still need answer

dsig

David Tod Sigafoos ~ SigSOlutions

dsig@teleport.com cis:70302,77 voice:503-639-8080


At 02 JUN 1998 12:50PM Cameron Purdy wrote:

dsig,

I forwarded your original post to our Q/A group to ensure it was reproduced/entered in our SPR system.

Cameron Purdy

info@revelation.com


At 02 JUN 1998 04:25PM DSig (SigSolutions) wrote:

Cameron,

Thanks .. if it is not reproducable could you please have someone contact me .. there is a series of messages here of others with the same problem AND I believe it was Dave Puci(?) who defined the problem parameters which makes it reproducable.

I do have a HACK which will work but when this gets out of beta and we release to the end users it will really be necessary to have the functionality.

thanks again

dsig

David Tod Sigafoos ~ SigSOlutions

dsig@teleport.com cis:70302,77 voice:503-639-8080


At 20 JUL 1998 10:30AM DSig (SigSolutions) wrote:

Cameron,

Just trying to be proactive .. do you know if they have found the problem AND if so do you think that it will be fixed for the 3.7 release? The ability for a user to 'launch' items in windows 95 (and 98) is very important. We are putting a blurb in our Beta docs that this will be available soon ..

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com cis:70302,77 voice:503-639-8080

*

Subject:

Re: REPOST RTI: Utility and Launching DocsAuthor:

Cameron PurdyDate:

06/02/98


dsig,

I forwarded your original post to our Q/A group to ensure it was reproduced/entered in our SPR system.

Cameron Purdy


At 20 JUL 1998 02:41PM Carl Pates wrote:

Hi DSig,

Did you ever try that utility I sent you?

Cheers

Carl


At 20 JUL 1998 04:07PM Carl Pates wrote:


At 21 JUL 1998 11:17AM DSig (SigSolutions) wrote:

Carl,

Yep .. as I mentioned I will be installling it today and then getting it to the testers on Wednesday …

The reason I keep buggin RTI is that OI should handle this type of thing .. shouldn't need external routines to 'launch' a program in windows ..

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com


At 22 JUL 1998 09:23AM Donald Bakke wrote:

DSig,

The reason I keep buggin RTI is that OI should handle this type of thing .. shouldn't need external routines to 'launch' a program in windows ..

I'm inclined to agree with you. However, I like to keep considering the fact that as a 16-bit/Win3.x application, OI has been given a lot of attention for doing things in Win95/NT that most legacy applications wouldn't dream of doing. I give Revelation Software a lot of credit for making this happen since it helps to keep development in Windows possible whilst we wait for jRev.

dbakke@srpcs.com

SRP Computer Solutions


At 22 JUL 1998 10:32AM DSig (SigSolutions) wrote:

]I'm inclined to agree with you. However, I like to keep considering the fact that as a 16-bit/Win3.x application, OI has been given a lot of attention for doing things in Win95/NT that most legacy applications wouldn't dream of doing. I give Revelation Software a lot of credit for making this happen since it helps to keep development in Windows possible whilst we wait for jRev.

I am sure that I missed something .. what does OI do (other than it's database) that other 16bit apps don't do? What controls does it have that others don't have? Like I said I am sure that I did miss something and I would to love to know .. I don't want to miss the good stuff ..

I am not sure that I understand your last bit .. are you saying that everything we are doing in OI is simply to stay alive until jrev? If I thought I was doing that to my clients I would have to look very deeply into myself as a developer. I use OI because of my knowledge of the model AND because of the database. A couple of the systems I have in the works rely on the model as they are coming from the PICK world. But if I thought OI was dead as soon as jrev hits the I would stop further development and move to another platform.

Of course, I too give RTI (cam and gene) a lot of credit for making OI do things that the original direction did not think of .. that does not mean that I do not want features that other 16 bit apps allow.

but then this is only my opinion ..

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com


At 22 JUL 1998 07:23PM Donald Bakke wrote:

DSig,

As I understand it, many 16-bit apps can't work with long directory/file names. Many don't run on NT. You can't get into the system to invoke 32-bit DLL functions. Simulating 95/NT style interface features can't be done. These are things that can be done in OI. Not all is easy and not all is built in by design, but it can be done.

My last comment was simply a reflection of our experience. Many of our clients are becoming concerned that investment in a Windows application won't run on the latest OS. OI does and it can even "look" like modern 95/98/NT apps so it eases this problem. JRev will,

course, make what concerns still linger disappear (unless, of course, jRev invents its own set of problems ).

dbakke@srpcs.com

SRP Computer Solutions


At 23 JUL 1998 10:18AM David Sigafoos wrote:

Don,

Good answers all.

I have been lucky to have 16bit development systems which work well (knock on wood) with win95/nt.

Once again I have been lucky in that most of my clients reason that the windows and web are the viable os/environment for the future. That careful planning and thought keeps one from a dead-end (though it can happen).

thanks ..

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com


At 23 JUL 1998 06:11PM Gene Gleyzer wrote:

David,

The Presentation Server uses the FindExecutable() function to figure out what executable is associated with the specified document.

The following is a quote from the latest MSDN:

Beginning of the quote

PRB: FindExecutable() Truncates Result at First Space in LFN

Last reviewed: December 11, 1995

Article ID: Q140724

The information in this article applies to:

Microsoft Win32 Application Programming Interface included with:

  1. Microsoft Windows 95
  1. Microsoft Windows NT versions 3.1, 3.5, 3.51

SYMPTOMS

The FindExecutable function is supposed to retrieve the fully qualified path to the executable (.exe) file associated with the specified file name. For example, the following call to FindExecutable() should return the path to Winword.exe:

 FindExecutable ("C:\\README.DOC", NULL, szBuffer);

Assuming Winword.exe is currently in the C:\Msoffice\Winword directory, the function, upon return, should fill szBuffer with the string C:\Msoffice\Winword\Winword.Exe.

However, when you use FindExecutable() on a file whose associated application is in a directory that has a long file name (LFN) that includes a space, the function truncates the string up at the first space. Going back to the previous code example, if Winword.exe is located in the C:\Program Files\My Accessories directory, the function incorrectly returns the truncated string C:\Program instead of the following expected string:

 C:\Program Files\My Accessories\Winword.Exe

CAUSE

File associations are stored in the registry under HKEY_CLASS_ROOT, where the executable name is actually stored under the key

 HKEY_CLASSES_ROOT\\shell\open\command=

By design, long file names stored in the registry should be enclosed in quotation marks. Otherwise, the system is made to treat the rest of the characters following the space as arguments.

In the example, the path to WinWord.Exe should be stored in the registry as:

 HKEY_CLASSES_ROOT\Word.Document.6\shell\open\command =
  "C:\Program Files\My Accessories\Winword.Exe" /n

which does causes FindExecutable to return the expected string.

Note that this problem does not occur when the short path name is stored in the registry, instead of the long file name. Again, taking the same example to WinWord.exe, this should not be a problem if the short path name "C:\Progra~1\MYACCE~1\WINWORD.EXE" is stored in the registry instead of the LFN version.

WORKAROUND

In some situations, applications do not have control over what gets stored in the registry. It may be the associated application's setup program that wrote the incorrect LFN string (without quotation marks) to the registry. Any application that would then call FindExecutable() on this associated application will run into this problem.

One workaround to this problem might be to parse the string returned and replace the \0 character with a space. Stepping through a debugger, after FindExecutable() returns, you will quickly find that although the space has been replaced with the NULL character (\0), the rest of the string is left intact, so simply reverting the \0 character back to a space gives the expected string.

*** End of the quote

Indeed, as soon as I changed (as recommended)

 "C:\Program Files\My Accessories\Winword.Exe"

to

 "C:\Progra~1\MYACCE~1\WINWORD.EXE"

everything worked OK.

However, I'll try to figure out a way to use their second work-around – trying to substitute '\0' with the space in a generic way…

Gene


At 24 JUL 1998 02:05AM David Sigafoos wrote:

Gene,

Thank you very much for your response .. we have worked out various methods to get around this but it usually requires the user define where word or wordperfect etc reside.

When I installed my Office 97 the default location for office was "c:\program files\microsoft office\office\winword.exe". So from the get go this causes problems.

Not to tell you your job .. but you might want to get a hold of Carl Pates as he seems to have create a routine with fixes for this problem by calling his routin instead of Utility. I would, of course perfer to use a basic part of OI than an second party utility.

Thanks again for the response ..

Dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com


At 24 JUL 1998 08:26AM Gene Gleyzer wrote:

David,

the problem is not in the location itself. The problem is in which way (long file names or the equivalent short file names) this location is presented in the system registry for document assosiation.

However, I'd love to know what Carl has done. Carl, are you there?

Thanks,

Gene


At 24 JUL 1998 10:53AM David Sigafoos wrote:

]the problem is not in the location itself. The problem is in which way (long file names or the equivalent short file names) this location is presented in the system registry for document assosiation.

I *think* we are in a symatic thing here .. The location is important because that is what is put into the registry. I should have been more specific .. used REGISTRY .. but just went to short hand. Othere might be reading and sometimes eyes glaze over when discussion turns to registry etc..

Hope Carl replys .. of course they might have to charge RTI a big fee for fixing this problem.

thanks again for the follow up .. for the users we are targeting this 'launch' capability seems to be a hot button

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com


At 24 JUL 1998 12:32PM Gene Gleyzer wrote:

David,

I'm not sur what you mean. The Windows API (FindExecutable) corrups the data comming from the registery. Other wise it would work. We plan to provide a work round if posible.

Gene.


At 24 JUL 1998 02:26PM Andrew McAuley wrote:

[notag]Carl's on holiday at the moment for a week. He's doing a shellexecute to the 32 bit API call I think.

We're developing something called zzutility32 in which we are building all the calls we want. We'll probably then market it.

Toodles

[<A HREF="mailto:amcauley@sprezzatura.com" onMouseOver="window.status='Why not click here to send me Email?';return(true)">Andrew McAuley</A>]

[<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Why not click here to visit our web site?';return(true)">Sprezzatura Ltd</A>]

[<I>World Leaders in all things RevSoft</I>]

[<B><I>When do you want to reboot today?</B></I>]

[<img src="http://www.sprezzatura.com/zz.gif">]

[<HEAD>]

[<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0";}end hiding from non-JS browsers –></script>] [</HEAD>] [<FORM ACTION "" METHOD=GET NAME="TOCNavigator" <SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()"> <OPTION>Pull down this menu to choose whereabouts on Sprezz site to go <OPTION VALUE="http://www.sprezzatura.com">Home Page <OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New <OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL <OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST <OPTION VALUE="mailto:support@sprezzatura.com">Send mail to support at Sprezzatura <OPTION VALUE="mailto:sales@sprezzatura.com">Send mail to sales at Sprezzatura </SELECT> </FORM>][/notag] </QUOTE> View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/be45d534b35074dd8525661400787274.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1