How to make iconx script file minimize

[Thomas]

I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't.

You could do this with two scripts. You double click on script1 which contains just this:

Code: [Select]


newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2


[guest11527]

All I want to know is if there's a way to start the script in fullscreen from Workbench without IconX and the answer is nya... it doesn't exist in ROM, it doesn't even exist in other OS3.x files so I'd have to resort to a 3rd party tool for this and although it would solve the issue if someone try start the script when IconX isn't present I'm not sure I have the extra 2.5KB space for the extra tool. I'll have to wait and see how my project evolves.

Note, also, that starting of shell scripts from the workbench with a double click is a feature that was added to the 3.5 or 3.9 workbench. So 3.1 users will not have it. IconX is, however, part of the 3.1 distribution, so it should be on everybody's workbench in the C: directory. In worst case, you can supply a similar tool along with your program. (Hint: I would have little problems allowing that for CLICon).

However, if I may: I would still strongly suggest to use the installer. It's really what it's good for, and users know it. In the end, it's of course your decision, I'm just giving a well-meant advice.

[Brian]

You could do this with two scripts. You double click on script1 which contains just this:

Code: [Select]


newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2


Looks to be exactly what I need (was trying to do but in the wrong order I guess... executing a script and direct output it to a new CON: which didn't work since all outputs still came to the first one). Will play with this a bit but looks promising!

Note, also, that starting of shell scripts from the workbench with a double click is a feature that was added to the 3.5 or 3.9 workbench. So 3.1 users will not have it. IconX is, however, part of the 3.1 distribution, so it should be on everybody's workbench in the C: directory. In worst case, you can supply a similar tool along with your program. (Hint: I would have little problems allowing that for CLICon).

However, if I may: I would still strongly suggest to use the installer. It's really what it's good for, and users know it. In the end, it's of course your decision, I'm just giving a well-meant advice.

From my experienced if you set the scripts S protection bit, give it a tool icon (instead of project) and add CLI to it's tooltypes it'll start perfectly fine with just KS3.1... need to verify 3.0 compatibility though.

I understand your good intentions and I appreciate them but Installer is simply too large for this application.

The project is to get as much of OS3.1 onto a single DD floppy and have the floppy work as a standalone disk with all the original functionality still there and it need to work with as little as 68000 and 1MB of memory. I'll spare you the details of what I've had to do to make it work, lets just say I've optimized, crunched and packed a bit and apart from IconX's dependencies it work brilliantly and installs about 2.4MB of the original 3.1 content (so not everything but with no real "essentials" missing).

[Brian]

You could do this with two scripts. You double click on script1 which contains just this:

Code: [Select]


newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2


The code did what I expected it to do but failed to solve the imaginary issue I've created (where someone boot with a floppy that are missing key OS files and then try to access my disks). I hoped I could get around to execute my script with no diskbased dependencies cause from there I could solve all issues. With the code IconX get's taken care of but I'm still stuck with needing Execute to be present (far more likely but still not certain).

I figured the newshell likely would need the Execute command (since IconX do) but I had hoped it wouldn't (since S:startup-sec don't).

[guest11527]

With the code IconX get's taken care of but I'm still stuck with needing Execute to be present.

NewShell/NewCLI does not require Execute. It's the shell that executes the commands, not Execute. Execute is just a silly preprocessor. See "THOR's Shell Hacks" here in the forum.

[Brian]

NewShell/NewCLI does not require Execute. It's the shell that executes the commands, not Execute. Execute is just a silly preprocessor. See "THOR's Shell Hacks" here in the forum.

Yes, my bad. Execute wasn't needed by newshell line but by the way I start the script from the workbench icon.

You know of any other option to get the script to start via an icon other that said option where I have to set the S bit, give the script a tool icon and add CLI to tooltypes as this requires Execute to be present and also give you a prompt for arguments. I know I could simply add "newshell from" in front of the scriptname in the prompt but that's not really an option that works for Joe Novice.

[guest11527]

Yes, my bad. Execute wasn't needed by newshell line but by the way I start the script from the workbench icon.

Huh? Why? I do not really see where and why the workbench should require Execute as command. As said, the only thing the workbench does is to pipe the command name into the System() call, and that doesn't require Execute at all. Execute is not what you think. It is not responsible for command execution at all, despite its name.

[paul1981]

Yes, my bad. Execute wasn't needed by newshell line but by the way I start the script from the workbench icon.

May I ask what the benefit is supposed to be by loading your install script via a Workbench icon rather than via the startup-sequence? If the user only has a broken Workbench disk or none at all, why would they not want to boot from your install disk?

[Brian]

May I ask what the benefit is supposed to be by loading your install script via a Workbench icon rather than via the startup-sequence? If the user only has a broken Workbench disk or none at all, why would they not want to boot from your install disk?

Yes it's for my OS3.1 on a single DD floppy project and therefore you might have to start HDToolbox first so you have something to install onto. And you might need to format the disk first. You might even have to get hold of L:Fastfilesystem in case you got a really old controller with it's own software that require this on file instead of taking it from ROM or have KS3.0 and want the newer one. There's also a readme you might want to read but not all the time. If it wasn't for HDToolbox everything could be setup from startup-sequence but since it isn't I want to load Workbench and have the options run from there to get a "unified" feel.

[Brian]

Huh? Why? I do not really see where and why the workbench should require Execute as command. As said, the only thing the workbench does is to pipe the command name into the System() call, and that doesn't require Execute at all. Execute is not what you think. It is not responsible for command execution at all, despite its name.

When I try it, script given the S protection bit and a tool icon that have CLI in it's tooltypes, I clearly get "Execute unknown command" before any line of code in the script has been started.

Since I don't know how, could you please tell me how you would start a script by just double clicking an icon in workbench without having to type anything manually and only using KS3.0 ROM commands (no on disk commands like IconX, Execute etc)?

[paul1981]

When I try it, script given the S protection bit and a tool icon that have CLI in it's tooltypes, I clearly get "Execute unknown command" before any line of code in the script has been started.

Since I don't know how, could you please tell me how you would start a script by just double clicking an icon in workbench without having to type anything manually and only using KS3.0 ROM commands (no on disk commands like IconX, Execute etc)?

I think Thomas meant you to use

newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2

as the default tool in a project icon. I haven't tried it but it looks like it would work.

EDIT: No, don't try that as it doesn't work under 3.1 (like he said it wouldn't). If you get rid of the "newshell" part and make the default tool "con:0/0/...." then it opens a window but I don't think it's possible to make it execute commands. Thomas may know a trick or two though...

EDIT2: If you look at the Workbench:System/Shell you'll see that it uses the default tool 'CLI'... CLI is 1180 bytes (less bytes than IconX), so this is a possibility. Make the project icon, make its default tool 'CLI' and then add some tooltypes. CLI must be somewhere in the path (sys or c etc)

WINDOW=CON:0/0/500/100/title/CLOSE/WAIT
FROM=yourscript

Your icon needs to be just 1 pixel with no second image to save space.

[paul1981]

If it wasn't for HDToolbox everything could be setup from startup-sequence but since it isn't I want to load Workbench and have the options run from there to get a "unified" feel.

HDToolbox doesn't need Workbench. Delete the icon (.info) here too to save space.