You make some good points.
Here is a modified version of my change that produces a good response, in my
opinion, to browse errors in Windows:
browse=: 3 : 0
...
try.
if. IFUNIX do.
2!:1 cmd, (0=nox)#' &'
elseif. IFWIN do.
r=.>0{ShellExecute(0;'open';cmd;NULL;NULL;SW_SHOWNORMAL)
if. r<33 do. 'browse error' 13!:8 255 end.
elseif. do.
fork_jtask_ cmd
end.
catch.
msg=. 'Could not run the browser with the command:',LF,LF
msg=. msg, cmd,LF,LF
msg=. msg,'You can change the browser definition in
Edit|Configure|Base',LF,LF
sminfo 'Run Browser';msg
end.
This version of browse gives this response in GTK:
http://www.jsoftware.com/jwiki/DavidMitchell?action=AttachFile&do=view&target=runbrowseboxgtk.png
It gives this response in J console:
browse_j_'foo'
+-----------+-------------------------------------------------------------------
------------------------------------------------------------+
|Run Browser|Could not run the browser with the command: "xxx" "file://foo" Yo
u can change the browser definition in Edit|Configure|Base |
+-----------+-------------------------------------------------------------------
------------------------------------------------------------+
While the J console message is not precisely accurate for J console users, I
think it does indicate, in a general way, what the problem is.
This change allows Windows to use file associations if Browser is null and
allows GTK to report problems should anyone want to use a non-default browser
and has not set up the Browser information correctly.
I did find I was wrong about Linux 2!:1 giving useful results, at least in all
cases. I tried my change on Linux and discovered that 2!:1 does not return a
useful result when the command supplied is run in the background with a
terminal &.
One small nit to pick about Linux and default browsers. I took a (very quick
and I am sure very incomplete) look at Linux substitutes for Windows file
associations. I found that many Linux versions seem to use MIME Types as a
functional equivalent of Windows file associations. It does not seem to be as
well supported as Windows file associations, but there does seem to be growing
support for MIME types as a way to centralize this information, including the
Linux default HTML browser.
For example:
http://askubuntu.com/questions/16580/where-are-file-associations-stored
I'll see if I can determine if J in Linux could use MIME types to give more
reliable results.
On 1/22/2011 20:08, bill lam wrote:
> I agree that fork_jtask_ is over-skill for browse and shellexecute is a
> simpler way to do it. But I still unsure if returning an error code for
> browse could be helpful because,
> 1. there should already enough or lack of visual feedback to indicate error
> had
> occurred.
> 2. the gtkide itself cannot do anything to rectify the error.
> 3. users or sys admin for that matter is responsible for setting up
> Browser_j_ or leaved it as to the default empty string.
>
> I cannot see why choice of browser can be configurable is a bad thing in
> gtkide. Incidentally Linux does not have default browser.
>
> I'll incorporate your shellexecute code into browse.
>
> Сбт, 22 Янв 2011, David Mitchell писал(а):
>> Well, there is at least an indication of an error in Linux when its fork verb
>> fails. It is not as sophisticated as the values returned by the Windows
>> ShellExecute facility but it seems as if this could be used to at least
>> determine if the forked task in Linux had some level of success:
>>
>> fork_jtask_
>> 2!:1
>> fork_jtask_ 'foo'
>> |interface error: fork_jtask_
>> | fork_jtask_'foo'
>> fork_jtask_ '\\html'
>> |interface error: fork_jtask_
>> | fork_jtask_'\\html'
>>
>> There is no indication of any error when the Windows fork_jtask_ fails.
>>
>> Finally, Windows provides the association mechanism and already maintains my
>> preferred default browser information. I'm not sure I see the utility in
>> having
>> to manually maintain information about my default browser in J as well,
>> especially when avoiding the use of ShellExecute in Windows decreases the
>> intrinsic reliability of J. It's not as if there are not other places where
>> J
>> uses differing verbs for supporting OS functions on different OSes.
>>
>> On 1/21/2011 11:26, bill lam wrote:
>>> That error information is helpful but only available in window shellexecute
>>> not linux, and also the Browser is manually set by user who should have
>>> some idea of the browser's full path name. There is not too many
>>> possibilities
>>> for failure and should be easy for track.
>>>
>>> Just my two cents.
>>>
>>> Птн, 21 Янв 2011, David Mitchell писал(а):
>>>> I forgot that the config files were saved in the user J7 dir. I removed
>>>> all j7
>>>> dirs and reinstalled using the new install packages.
>>>>
>>>> I can confirm that the new installed config value for the base Browser is
>>>> '' for
>>>> Win on both J701_64 and J701_32.
>>>>
>>>> I agree that a pop up box would not be an appropriate way to handle an
>>>> error
>>>> with the browse verb. But, my changes do not generate a pop up box.
>>>>
>>>> Also, I still find the current behavior of no error response at all when
>>>> the J7
>>>> Browser configuration is misconfigured is not helpful and could be
>>>> improved.
>>>>
>>>> As far as I can tell, my suggested changes work fine in both jconsole and
>>>> gtkide
>>>> and they do reduce the risks of using fork_jtask_.
>>>>
>>>> fork_jtask_, as far as I can see, in its current form, will never give any
>>>> indication of failures.
>>>>
>>>> ShellExecute, on the other hand, does return useful values on a failure
>>>> that
>>>> could be used in any environment to at least give the user some
>>>> notification of
>>>> why the 'browse' is failing:
>>>>
>>>> cmd_j_=:'foo.exe'
>>>> ShellExecute_j_(0;'open';cmd_j_;NULL_j_;NULL_j_;SW_SHOWNORMAL_j_)
>>>> ┌─┬─┬────┬───────┬───┬───┬─┐
>>>> │2│0│open│foo.exe│┌─┐│┌─┐│1│
>>>> │ │ │ │ ││0│││0││ │
>>>> │ │ │ │ │└─┘│└─┘│ │
>>>> └─┴─┴────┴───────┴───┴───┴─┘
>>>> cmd_j_=:'\\gabble'
>>>> ShellExecute_j_(0;'open';cmd_j_;NULL_j_;NULL_j_;SW_SHOWNORMAL_j_)
>>>> ┌─┬─┬────┬────────┬───┬───┬─┐
>>>> │3│0│open│\\gabble│┌─┐│┌─┐│1│
>>>> │ │ │ │ ││0│││0││ │
>>>> │ │ │ │ │└─┘│└─┘│ │
>>>> └─┴─┴────┴────────┴───┴───┴─┘
>>>> cmd_j_=:'http://www.jsoftware.com/docs/help701/index.htm'
>>>> ShellExecute_j_(0;'open';cmd_j_;NULL_j_;NULL_j_;SW_SHOWNORMAL_j_)
>>>> ┌──┬─┬────┬───────────────────────────────────────────────┬───┬───┬─┐
>>>> │42│0│open│http://www.jsoftware.com/docs/help701/index.htm│┌─┐│┌─┐│1│
>>>> │ │ │ │ ││0│││0││ │
>>>> │ │ │ │ │└─┘│└─┘│ │
>>>> └──┴─┴────┴───────────────────────────────────────────────┴───┴───┴─┘
>>>>
>>>> Any return value greater than 32 is ok. Here are two of the errors that
>>>> can be
>>>> reported:
>>>>
>>>> #define ERROR_FILE_NOT_FOUND 2L
>>>> #define ERROR_PATH_NOT_FOUND 3L
>>>>
>>>> The return value from ShellExecute could be used to either create a signal
>>>> for
>>>> an error or generate a return value for the browse verb that would
>>>> indicate if
>>>> it was successful or not, and, if not, why not.
>>>>
>>>> On 1/21/2011 8:49, bill lam wrote:
>>>>> A fresh installation from a recent window installer probably unset
>>>>> Browser in its default config so it should work out-of-box. The verb
>>>>> browse
>>>>> is shared by jconsole and gtkide so I didn't wish it to pop up a message
>>>>> box for warning information.
>>>>>
>>>>> Птн, 21 Янв 2011, David Mitchell писал(а):
>>>>>> Hi Tikkanz,
>>>>>>
>>>>>> Yes, the problem I see only exists with J7_64. I just downloaded and
>>>>>> installed
>>>>>> new versions of J7_32 and J7_64 to make sure.
>>>>>>
>>>>>> This is what I found;
>>>>>>
>>>>>> JVERSION
>>>>>> Engine: j701/2011-01-10/11:25
>>>>>> Library: 7.01.033
>>>>>> Platform: Win 32
>>>>>> Installer: j701a_win.exe
>>>>>> InstallPath: c:/users/me/j32_j701c/j701
>>>>>> #Browser_j_
>>>>>> 0
>>>>>>
>>>>>> JVERSION
>>>>>> Engine: j701/2011-01-10/11:25
>>>>>> Library: 7.01.033
>>>>>> Platform: Win 64
>>>>>> Installer: j701a_win64.exe
>>>>>> InstallPath: c:/users/me/j64_j701c/j64-701
>>>>>> Browser_j_
>>>>>> 44
>>>>>> Browser_j_
>>>>>> c:/program files/mozilla firefox/firefox.exe
>>>>>>
>>>>>> My default browser is:
>>>>>>
>>>>>> C:/Program Files (x86)/Mozilla Firefox/firefox.exe
>>>>>>
>>>>>> So, the two versions of J7 have differing definitions of Browser_j_. The
>>>>>> default Browser_j_ from base.cfg used in J7_64 does not point to a valid
>>>>>> exe and
>>>>>> attempting to use it in fork_jtask_ does not result in any message
>>>>>> indicating
>>>>>> what has happened.
>>>>>>
>>>>>> If you want to continue to use fork_jtask_, this will protect J from
>>>>>> errant
>>>>>> Browser settings:
>>>>>>
>>>>>> stdlib.ijs
>>>>>>
>>>>>> ...
>>>>>> try. 1!:4<Browser_j_ catch. Browser_j_=:'' end.
>>>>>> browser=. Browser_j_
>>>>>> --
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> On 1/21/2011 4:33, Tikkanz wrote:
>>>>>>> Hi David,
>>>>>>> The items on the Gtk IDE help menu seem to work ok for me without any
>>>>>>> Browser set on 32bit Win7.
>>>>>>> The pages (online versions because I haven't downloaded the docs/help
>>>>>>> addon) open fine in my default browser (Firefox).
>>>>>>> #Browser_j_
>>>>>>> 0
>>>>>>> JVERSION
>>>>>>> Engine: j701/2011-01-07/14:33
>>>>>>> Library: 7.01.037
>>>>>>> Platform: Win 32
>>>>>>> Installer: j701a_win.exe
>>>>>>> InstallPath: c:/users/ric/j701
>>>>>>>
>>>>>>> The browse_j_ verb attempts to something similar to what you describe
>>>>>>> below.
>>>>>>>
>>>>>>> On Fri, Jan 21, 2011 at 9:08 AM, David Mitchell<[email protected]>
>>>>>>> wrote:
>>>>>>>> I was puzzled when none of the 'help' menu options did anything in J7
>>>>>>>> GTK. I
>>>>>>>> looked at the code and saw that I needed to configure a hard-coded
>>>>>>>> path to my
>>>>>>>> browser of choice.
>>>>>>>>
>>>>>>>> Being lazy, I offer this small change to stdlib.ijs that eliminates
>>>>>>>> the need to
>>>>>>>> specify a browser in J7 and allows J7 to use the Windows system file
>>>>>>>> associations. I have tested it on Win7 and WinXP successfully.
>>>>>>>>
>>>>>>>> NB. Insert 1
>>>>>>>> ShellExecute=: 'shell32 ShellExecuteA i i *c *c *c *c i'&cd
>>>>>>>> SW_SHOWNORMAL=:1
>>>>>>>> NULL=:<0
>>>>>>>> NB. End Insert 1
>>>>>>>> browse=: 3 : 0
>>>>>>>> cmd=. deb y
>>>>>>>> isURL=. 1 e. '://'&E.
>>>>>>>> if. IFJHS do.
>>>>>>>> cmd=. '/' (I. cmd='\') } cmd
>>>>>>>> if. -. isURL cmd do.
>>>>>>>> if. -.fexist cmd do. EMPTY return. end.
>>>>>>>> cmd=. 'file://',cmd
>>>>>>>> end.
>>>>>>>> redirecturl_jijxm_=: cmd
>>>>>>>> EMPTY return.
>>>>>>>> end.
>>>>>>>> NB. Insert 2
>>>>>>>> if. IFWIN do.
>>>>>>>> cmd=. '/' (I. cmd='\') } cmd
>>>>>>>> if. -. isURL cmd do.
>>>>>>>> if. -.fexist cmd do. EMPTY return. end.
>>>>>>>> cmd=. 'file://',cmd
>>>>>>>> end.
>>>>>>>> ShellExecute(0;'open';cmd;NULL;NULL;SW_SHOWNORMAL)
>>>>>>>> EMPTY return.
>>>>>>>> end.
>>>>>>>> NB. End Insert 2
>>>>>>>> ----------------------------------------------------------------------
>>>>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>>
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
