RunRev versus WinRar

MisterX b.xavier at internet.lu
Sat Apr 9 07:00:49 EDT 2005


> > On Apr 8, 2005, at 10:33 PM, Richard Gaskin wrote:
> >> The real culprit here is Microsoft, for not bothering to create a 
> >> registry for file types to be associated with specific 
> applications.

30 seconds search yielded the microsoft page regarding this subject in
general. Not a list but the reason why there isn't one. 
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl
atform/shell/programmersguide/shell_basics/shell_basics_extending/fileassoci
ations/fa_file_extensions.asp>

in sum, the list is already in the registry of your windows installation,
the rest is up to you as is the usual windows culture...

Ignorance of the enemy is a sure way to defeat - Sun Tzu

> But on Windows, in the absence of any guidance from the 
> mother ship developers are left to their own devices, hoping 
> and praying their file extensions don't conflict.

> A few developers have taken it upon themselves to try to 
> compensate for Microsoft's inattention to this critical 
> aspect of OS design, maintaining databases of file extensions 
> and associated apps.

There is no global registry but there are plenty of sites with the links or
reference to any file extensions. On Windows, it's your job to know, not
Apple's or Microsofts - and that's why QT has been a big pain in the hind
each time it overides the file types or display settings! 

What I find funny however is the OT inferences made against a product that
do have a complete tool set to cope with this issue and not mentioning it.
Not that I like Moft but if you're not capable of coping with MS security
issues, why even mention it? What is the point within file types assignment?
A previously mentioned tip reference would have been more helpful. If I find
security issues a more benefitial than a small-OS-market it's my problem not
a reason to evangelize an over-priced product, let alone justify the
rev-pref for mac os which is a thorn in itself sometimes. See my second
point...

Anyway to resolve your "Rev" extension issues on windows:

Note there's no way to change the rev extension via the preferences but you
are free to do so in your scripts! 

Open an explorer window (windowkey+E), go to tools, open options, click on
the file extensions tab and click on "advanced" (w2k or newer) now you can
edit or set what "context menu" item will (by default) open, edit, or spit
your file the way you want. Including having more than one app for any
application. That way you can overide any Moft app editing or opening your
html files or insuring Rev opens your stacks. I find that much more flexible
than all I ever saw coming down from Apple except for alias to drop onto
;)...

The second point... Why the above is irrelevant...

I'd rather rant on another similar but more basic (pain in the ***) type of
issue:

Rev still can't open stacks normally on PCs when you double click on it's
documents - the stacks or your application's stack-documents... Win32 always
opens another session of Rev, this is still not handled correctly on windows
since 4 years and there's no alternative. Im pretty sure I mentioned it
before to Scott or Kevin but haven't seen complains and made my own
solution...  But you can't send shell commands to runrev or double click a
second document or you'll have this second runrev session and you'll surely
get a stack-overwrite problem... Now, that's a security risk for file
integrity if I've ever seen one!

Any file assignment is just a simple plain-old shell assign command any
Windows that users should be aware of like the paths variables. But there's
nothing we can do for the extra Rev sessions opening other than rewriting a
file explorer for my Rev sessions... 

How does it work on Mac OSX? MacOS? 

Do you get an extra rev session when you doubleclick a stack or does rev
open it "normally" as a second stack window? 

Just my 2 cents and probably another 2 new bugzillas for tomorow!

cheers
Xavier
--
http://monsieurx.com/runrev





More information about the use-livecode mailing list