How to make iconx script file minimize

[Brian]

I made a script into an executable which works but the window cannot be button or minimized.

Have you set the WINDOW tooltypes for IconX?

WINDOWS=CON:0/50//80/IconX/AUTO/WAIT/CLOSE

Install KingCON and you will have a minimize option.

[Brian]

OK, since I only get answers that for me are irrelevant and not really what I am asking about, I assume then that there is no difference between using IconX and setting S bit and tooltype CLI

I could imagine that IconX for example could read more tooltypes, there are IconX "clones" that can do a lot more.

I don't know how you would set shell size and title without IconX... with CLI you just get a shell that ignores S:shell-startup as far as I can see (or have I missed something).

With IconX you don't have to confirm the action after the double click  on the icon.

[Brian]

STACK is not a tooltype, but a fixed entry in the DiskObject. Otherwise, the differences between SYS:System/CLI, SYS:C/IconX and the workbench start are indeed minor. All of them end up in SystemTagList() to run the shell script, with one subtle difference that CLI and IconX first create a dummy CLI structure from the template in the workbench task. The workbench itself does not need to, it already has a CLI that is cloned by SystemTagList().

There are various re-implementations of IconX that are considerably more powerful than IconX. CLICon, for example, also allows arguments by selecting the "script icon" along with another icon "as argument".

Do you know if there's a way to set the size of the window if you use the S-bit and start the script as a tool with "CLI" as tooltype?

I thought I might be able to just ass a line in the script execute script2 >CON:0/0/640/100/Titel/WAIT/CLOSE but that only create a new shell on top of the old one and the scripts continues with it's outputs on the first window.

[Brian]

There is none. The workbench computes a suitable size from the font size and the size of the workbench screen. It's always an approximate 80x16 console window


Correct. If you need this, use CLICon or IconX. The former allows many more options.

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.

[Brian]

You cannot even start the workbench by only relying on what's in ROM (note that at least "LoadWB" is disk-based), so I wonder why this is a useful criterion.

I know that but I have a floppy that start an extremely minimalistic workbench and includes a DOS script as an install option. I'd love to be able to start that script without rely on IconX or Execute to be present, that way I can be sure it'll start no matter what device or floppy you boot from... however the shell need to be in full screen and I don't want to force the user to manually do that.

Just looking into what options I have.
1) Ignore and accept that it'll fail in the cases where user boot from a different floppy.
2) Put IconX and Execute on the floppy, however if not in the same device (say they use DF1) it'll still fail.
3) Rely solely on ROM based alternatives (doesn't seem to be possible)
4) Rely ROM based alternative in combination with 3rd party software such as CLIwindow.

[Brian]

Frankly, if installation is your problem, write an installer script. Yes, that is disk-based, but my experience is:

No matter what you do, some user will screw up. Offer something that is known and convenient for 90% of the users. 10% will complain no matter what you do (and unfortunately, you will only receive feedback from them, positive feedback is rare), so address the 90% as good as you can, with the tools they know. That's the installer.

The script is quite foolproof and req. minimal input from the user and I opted for a DOS script to save space and memory (everything is archived, even bootfiles and install tools/script, and are extracted to RAM: on startup).

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.

There is, it's called the Startup-Sequence. If you wanted to, you could still load Workbench and keep the AmigaDOS shell open by omitting the EndCLI after LoadWB. That is, I'm assuming your floppy is bootable?

I understand how you're thinking and it could have been a good idea if it wasn't for the fact that Install isn't the only function of the disk and one of the others have to be started from it's icon in Workbench to work... so for a cleaner look everything goes through Workbench. But I do like your outside the box thinking.

[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).

[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.

[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)?