I did put my root window resize script in WBStartup, it works but i get an empty window "WAIT" showing up and then a requester saying no return is observed, and if ai want to wait any longer.
- Exit is not needed - " " should not be used (they may be harmful though) as an example I use: address workbench KEYBOARD ADD NAME open KEY 'return' CMD "'MENU INVOKE ICONS.OPEN"
His usage of quotes is actually correct as arexx commands are strings, your code works as arexx concatentates tokens inot strings by default.
workbench must be UPPER CASE! Portnames are case sensitive thus workbench does not equal WORKBENCH , it appears to work as the workbench token is not yet assign so defaults to it's literal value of WORKBENCH. As such the script works but it's bad habbit and should be voided, especially in examples to learning users
@ Jo Duchit.
Likewise Workbench should be WORKBENCH
You have your OPTIONS RESULTS in the commenty which may not be what you want.
After all pedantism the solution to your problem is to click on Information in the WBStartup prefs window to open the scripts icon in WBStartup mode, then unslect
Wait until finished
in the Icon tab
*OR*
Manually add the DONOTWAIT tooltype via the normal icon information window.
You're right about the WORKBENCH port needing to be upper case. However, his script should return fast enough to not be affected by the "Wait until finished" option. The WBStartup "Wait until finished" option is broken. You can test it for yourself:
Create a simple AmigaDOS script with a command like "echo testing >ram:test.
Make sure the script protection bit is set.
Add a tool icon for the script with "Start From" set to Shell.
Add the script to WBStartup.
Use WBStartup "Information" to checkmark the 'Wait' option and change the wait time to 10 seconds.
Reboot and you will get a "Still not returned/Wait some more" requester.
If you keep clicking the button to wait some more, several seconds later you will get another requester. If you open a shell and enter "dir ram:" you will see that the echo command completed and the file "test" is present.
You can also test the Wait option with other commands or programs that perform some function and return (exit).
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
The seem to remember that the issue here is that there is no WBStartup message to reply to in the case of scripts sarted from shell or ARexx. Thus WBstartup doesn't get a reply to WAIT for. So *must* set DONOTWAIT for scripts (be they DOS or ARexx) *or* IconX to start the script if it's one that you need to wait for.
@broadblues You're right. I compiled a small test program and confirmed your explanation. In that case it appears that we should be starting commands and scripts from user-startup instead of WBStartup.
It also seems to imply that WorkBench will be waiting indefinitely for any scripts or commands started from an icon and not releasing any memory associated with starting a non-WorkBench command or script.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
You're right. I compiled a small test program and confirmed your explanation. In that case it appears that we should be starting commands and scripts from user-startup instead of WBStartup.
Depends on the function of the script, if it requires the Workbwnch ARexx port to be present then you pretty much have to start from WBStartup. There is no problem with doing this as far as I can see, you just have to set the DONOTWAIT option. I suppose theonly time there might be an issue is if you create a script that *must* be waited for that you want to run in your WBStartup, but what that would be I've no idea and I suspect is not a real usage case.
Quote:
It also seems to imply that WorkBench will be waiting indefinitely for any scripts or commands started from an icon and not releasing any memory associated with starting a non-WorkBench command or script.
It doesn't 'seem to imply' anything of the sort. Your putting 2 & 2 together and making 5 there.
Workbench doesn't wait for programs launched from it as far as I'm aware except in the special case of WBStartup.
For example run a script from shell but using WBRun it will return imediatly.
thanks a lot. I was under the impression you just had the same "information" window as when you use it from the icn in the rexx: drawer.
This WBStartup mode has always been there, since the old WBstartup drawer approach (which can still be used as afall back BTW). Even the basic non RAWBinfo window has a WBStartup mode.
Quote:
I guess this has the same effect as putting a tootlype DONOTWAIT and after verification: this tooltype was added.
It doesn't 'seem to imply' anything of the sort. Your putting 2 & 2 together and making 5 there.
I suppose you're right. I did some more testing and programs started from an icon with "Start from: Shell" are not receiving a Workbench startup message but "Start from: Workbench" are getting a startup message.
Quote:
Workbench doesn't wait for programs launched from it as far as I'm aware except in the special case of WBStartup.
Workbench is waiting for a reply to the Workbench startup message so it can free the startup message (and associated memory) and possibly any memory associated with keeping track of which processes are running or have exited.
Quote:
For example run a script from shell but using WBRun it will return imediatly.
WBRun is either detaching inself from the shell and waiting for the Workbench startup message reply or it is somehow passing the program/script name to Workbench for execution.
I'm guessing that when you select "Wait" in an icon for WBStartup, it is waiting for the reply to the startup message; which it never receives from a script started with "Shell" or "ARexx" set in the icon.
Starting a script (with Wait) from a project icon with iconx as the "Default tool:" should work in WBStartup because iconx is a Workbench program. It doesn't work so I think iconx needs some repair.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I suppose theonly time there might be an issue is if you create a script that *must* be waited for that you want to run in your WBStartup, but what that would be I've no idea and I suspect is not a real usage case.
If anybody ever had that need, the proper solution would be to put the two (or more) applications into one script, so they are serialized there, and then start the script as one entry in WBStartup.
If anybody ever had that need, the proper solution would be to put the two (or more) applications into one script, so they are serialized there, and then start the script as one entry in WBStartup.
Sort of what we do with Network-Startup.
To me that seems like a workaround for the fact that WBStartup "Wait" only works for programs started by Workbench. Using iconx as the tooltype "almost" works. The only problem is that WBStartup opens and immediately closes the "Wait some more" requester when the wait time is reached. I'm not sure if the problem is with iconx or WBStartup.
Adding network applications to a script defeats the purpose of having a GUI driven method of automatically starting applications after Workbench is loaded. If iconx worked as it should when used as a tooltype with WBStartup, the user could simply add a "wait" for network startup and set a lower priority for applications that depend on the network being active.
The above is just my opinion. I don't want to argue over it since people seem happy with the current way WBStartup is used.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
the user could simply add a "wait" for network startup
There is no such thing as a wait for network startup.
Since the network is started by the process running the Network-Startup script, the only safe way to wait for it is to put the waiting commands in the same script after the network startup.
It would of course be possible to code some command (or script?) which could check whether the network was up and otherwise sleep until it is or whatever. But it hardly seems worth it, when you can just start your programs from Network-Startup instead.
There is no such thing as a wait for network startup.
Since the network is started by the process running the Network-Startup script, the only safe way to wait for it is to put the waiting commands in the same script after the network startup.
O.K. You say that there is no such thing as "wait for network startup" but that there are "waiting commands". I can't argue with that logic.
My real point is that we need to fix "iconx" so that it can be used in WBStartup to wait for scripts to complete. By that I mean that you could set the DEFAULT TOOL in a script's icon (for a script in WBStartup) to "iconx" and checkmark (set) the "Wait until finished:" gadget. Currently, that seems to work but WBStartup opens and immediately closes the "Wait some more" requester (an annoyance).
I was wrong about the Network-Startup script because I forgot that the purpose was to avoid boot delays waiting for the network startup while assuring that commands that need access the network when started will not fail. I was thinking of starting the network from WBStartup so that programs with a GUI would not fail if the network is unavailable. However, that could slow down the system boot time and was a bad idea.
A better idea would be to set an environmental variable in the Network-Startup script (below AddNetInterface) that scripts could check before starting a GUI based program in WBStartup. Before anyone asks what programs you would want to start from WBStartup at boot-time, here are some examples:
YAM with "Check for new mail on startup" activated in the confuguration. Jabberwocky with "Auto connect on startup" activated in preferences. Any browser with an external start page.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
O.K. You say that there is no such thing as "wait for network startup" but that there are "waiting commands". I can't argue with that logic.
Sorry, that was not very clearly formulated. When I wrote "waiting commands", I meant whatever commands you have which need to wait until there is a working network, e.g. fetching the time or mounting a network drive etc.
Quote:
A better idea would be to set an environmental variable in the Network-Startup script (below AddNetInterface) that scripts could check before starting a GUI based program in WBStartup. Before anyone asks what programs you would want to start from WBStartup at boot-time, here are some examples:
YAM with "Check for new mail on startup" activated in the confuguration. Jabberwocky with "Auto connect on startup" activated in preferences. Any browser with an external start page.
All these examples could just as well be started directly from Network-Startup instead of from (a script run byIconX in) WBStartup => no need for any special "wait for network" magic or env variables. But of course the env variable trick should also work.
All these examples could just as well be started directly from Network-Startup instead of from (a script run byIconX in) WBStartup => no need for any special "wait for network" magic or env variables. But of course the env variable trick should also work.
Try it!
I did and it usually works; but by coincidence. If "AddNetInterface" finishes before LoadWB completes the opening of the Workbench screen and a program in Network-Startup attempts to open it's window on Workbench, the result is usually a boot failure. That being said, AddNetInterface is slow enough on most systems that a boot failure will never occur.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Maybe your env variable idea could be used in reverse? I.e. put a script into WBStartup which creates an env variable called e.g. "WBIsUp", and then check for that in Network-Startup before running programs which need to open on WB?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
