How to programmatically fight with WPS:URL objects
"Go to URL" action
Can anybody explain me how to permanently set the "Go to URL" action on the "open" menu of the URL object?
You can't under Warp v3.0. The WebEx class explicitly resets the default view each time a WebEx object is "awakened" (made visible when the folder it's in is opened). I know this for a fact because the code outputs this debugging message:
**WebExplorer:wpObjectReady(): wpSetDefaultView succeeded
Your only option under v3.0 is to use an EA editor to delete the .CLASSINFO extended attribute. Then the file will no longer be a WebExplorer_Url object and can be associated with WebEx (or rather, WebEx can be associated with files of type WebExplorer_Url). The file can still be dropped on WebEx to load the Url - WebEx looks at the type, not the object class, to determine whether you're dropping a Url or a file. (Confused? See URL objects.)
Under Warp v4.0 (Merlin), you won't have this problem because the new wpUrl class doesn't mess with your choice of default open actions. However, AFAIK, you will have to manually change each old WebEx object to open the browser you choose.
URL attribute: a guess
I think that this has to do with how the URL attribute is stored. Rather and an EA, I think that it is an ini file thing <sigh>. I found that object desktop's package system will work to transport URLs, or you can use a REXX program to rewrite 'em as webx URLs.
[Does URL objects refute this?]
URL objects
The WPS uses its .TYPE EA of "UniformResourceLocator" to assign it to the WPUrl class while NS/2 uses the EA to identify its special function. Without this EA, URL objects will revert to plain-text files when copied back into your system. You will have to reassign them a type to restore their functionality.
Some file objects belong to a particular class solely because their CLASSINFO EA says so. Warp 3's WebExplorer_Url class is an example. Even though these files have a .TYPE EA of "WebExplorer_Url" for NS/2's benefit, this class wasn't written to associate the type with the class. These files had to be explicitly created as "objects" (which always results in a .CLASSINFO EA) in order to belong to the WebExplorer_Url class. Stripped of their .CLASSINFO EAs, WebExUrls will also revert to plain-text files and you won't be able to restore them.
There's a frequent fundamental misunderstanding of what WebEx Url objects really are. They are nothing but files whose .TYPE EA is "WebExplorer_Url ". While WebEx and other apps may use PM's WPS interface calls to create them, WebEx itself is wholely ignorant of their object wrapper when it comes time to read them. As long as the app that originates a drag action identifies the file being dragged as a WebExplorer_Url, WebEx will be happy to accept and read it. The WPS need not even be loaded.
In Merlin, these files have become "WPUrl" objects and may or may not have the WebExplorer_Url .TYPE EA. However, the WPS still identifies them as such during a drag to keep WebEx happy. (Unlike the WebExUrl class, Merlin's WPUrl class is automatically associated with any file having this .TYPE EA.)
Here's an experiment or two to demonstrate the above: - use EPM (or any editor that doesn't add a Ctrl-Z to the end of a file) to create a file with a valid URL. After saving it, open the file's settings notebook, delete any Current Types, and add WebExplorer_Url from the list of Available Types. Now drag and drop the file on WebEx. The URL will be loaded, even though it isn't a "WebExplorer_Url" object. - start Merlin, then look at the file's Object Class in a Details view of its folder. You'll see that it's WPUrl. Open its properties notebook: it should be that of a Url object. If it isn't, you'll have to use the "Become" tab to make it one; after a restart, it will belong to the WPUrl class.
BTW... *no* WPS objects are "EAs hanging off the directory". If an object is filesystem-based, it has its own .CLASSINFO EA that is used by the WPS. If the object is abstract (like a Program reference object), the classinfo is stored in OS2.INI.