Conference hydra::amiga_v1

    
    I assume that you have NEWCON: mounted in your devs:mountlist?  What
    you have done SHOULD work, but it looks like your using the ARP shell,
    no?  Try it using the AmigaDOS shell and see what happens.
    
    Oh yeah, you must also have the following line in your
    startup-sequence..
    
    
    c:Resident CLI L:Shell-Seg SYSTEM pure add
    
    This command should be executed before you mount the NEWCON: device.
    
    Ed.
    
    
    

    Hmmm.   I think that the "WINDOW=" is what you want.  Capitalize
    "window" and try again.  
    
    Gary

    I've tried "WINDOW=", "window=", and other permutations of window,
    NEWCON, etc.  I first tried to change the SHELL/CLI window size with
    the "vanilla" workbench(V1.3) which I assumed mounted newcon.  I tried
    from the shell/cli, "newshell WINDOW=NEWcon:x/x/x..." and it couldn't 
    parse Window.
    
    I will verify that newcon: is mounted.  Since installing ARP/ASHELL I
    removed the line from "startup-sequence" refered to in <.1>, and hacked
    up STARTII and SHELL-STARTUP to get certain startup programs to run
    with ASHELL.  Do you have a SPECIFIC command that will work from the 
    shell command line?  What do YOU do to get your shell/cli windows to 
    size and place where your want them????
    
    
    thanks for the response 
    
    					mark "most confused" davis

    I use CONMAN, so in my Startup-sequence, I have "conman -d" and
    then I start with "Ashell con:0/0/640/200/Newshell".  Since I am
    running conman, that allows the f1 and f2 keys toggle to larger
    and smaleer windows.
    

You should be able to select  the SHELL icon, then pull down the Workbench
INFO menu. Go to the tool types and edit the window parameters to your liking
then click SAVE (did you click save?).

Now double clicking on the shell will do what you expect.

from the CLI  NEWSHELL NEWCON:x/y/w/h/name  should do the trick.

SOunds like newcon isn;t mounted.

Jon

    This is what I did.  I clicked on the SHELL icon.  Entered into the 
    tool types WINDOW=newcon:x/y/w/h/name (ret), then clicked SAVE.
    
    NEWCON: is mounted, I tried to mount it from the shell and it told
    me that it was already mounted.  Since I am running ASH I think I
    will install CONMAN and get my unnamed pipes working also.
    
    
    BTW, I tried to edit TOOL TYPES on my original WB diskette and the
    window didn't resize either!!!  curiouser and curiouser.  I assume
    I am doing something wrong.  Using quotes or not capitalizing or
    something.  I will try <.5> suggestion on a copy of my original
    WB diskette tonight.  Thanks all for the input.
    
    md

    Ditto on .4
    

just to be sure, NEWCON:x/y/w/h/name

Where:
	x and y is the location from top left of screen
	w and h are the width and height, in pixels
	name is what shows up in the title bar


Here's what's in my SHELL icon INFO:

	default tool: 	SYS:System/CLI
	tool types:	WINDOW=NEWCON:10/50/530/130/AmigaSHELL

I have ARP 1.3 installed and have
put Conlib.lib from CONMAN 1.3 into LIBS: and
put ConHandler from CONMAN 1.3 into L:


In my startup-sequence:

Resident CLI l:ASH SYSTEM pure add
LoadLib LIBS:ConLib.lib
Mount NewCON:


John

    I don't normally call my shell from Workbench, so I tried it.  You
    must change the default tool type to "c:ashell" and tool type to
    "WINDOW=con:x/y/w/h/name", you don't use the quotes.  In my startup,
    I don't make ash resident, I don't load conlib.lib, and I don't
    mount newCON:, instead I run "conman -d" and with the tool type
    set at "WINDOW=con:0/100/640/200/Ashell" I get a shell started in
    the lower half of my Workbench, I can resize it with f1 and f2 and
    it uses the "s:shell-startup" to setup all of my aliases and paths,
    etc.....Try it, it works for me....Steve
    

    excuse me: didn't verify before opening mouth, I run "conman -c"
    not "-d"...Sorry....Steve
    

  Well, as I thought, I knew just enough to be dangerous.  The reason
my shell windows were not sizing the way I wanted was because "h",
(x/y/w/h/name), was too large for the "screen" height.  I had "h" set
to 300 when the workbench screen is 200 or so.  Anyway, under
AmigaShell/CLI, when "h" is too large, the window size to "default" 
proportions.  Under AShell it will not open the window.

Now I will tackle speeding up my startup sequence.  Any suggestions? ;^)


mwd
    

> Now I will tackle speeding up my startup sequence.  Any suggestions? ;^)


Post what you got now and we'll all take a look!

John

If you are running ARP1.3, you get a pleasant speedup by doing all your 
assigns in one statement. With about 30 assignments in my startup-sequence,
I can get by with 3 or 4 activations of assign to do the whole thing.

	Dick

    
>Post what you got now and we'll all take a look!
    
    Here it is.  I have all my terminal utilities, dirutils, and qmouse
    on WB menu using MyMenu.  I am going to install an "IF" statement
    for conditional loading of RAD:(once I figure it out).  When the
    Ami is booted I have approx. 530000 bytes of memory left.
    



SYSTEM:		A500, 1MB memory, 2 floppy drives, ARP, default shell ASH.

			STARTUP-SEQUENCE
----------------------------------------------------------------------------

Addbuffers df0: 20
c:setpatch >NIL:
cd c:
echo "A500/A2000...Release 1.3 Version 34.20*N"
sys:system/fastmemfirst
failat 30
assign >NIL: RAD: exists
if warn
mount rad:
if not exist rad:c
	relabel drive rad: name ramdrive
	makedir rad:c rad:s rad:system rad:expansion rad:l
	copy (assign|copy|dd(dirutil)|delete|echo|else) radc: quiet quick
	copy (ares|list|cd|type|ashell) rad:c quick quiet
	rad:c/copy (endcli|endif|if|info|makedir) rad:c quiet quick
	rad:c/copy (newshell|path|prompt|move|run) rad:c quiet quick
	rad:c/copy sys:utilities/more rad:c quiet quick
	rad:c/copy :s rad:s all quiet quick
	rad:c/copy :system/format rad:system quiet quick
	rad:c/copy sys:shell.info rad: quiet quick
	rad:c/copy :l/disk-validator rad:l quiet quick
	rad:c/copy sys:expansion rad:expansion quiet quick
	endif
endif
failat 10
assign s: rad:s
path rad:c rad:system sys:util sys:system sys:prefs sys: s: add
sys:system/setmap usa1
assign sys: rad:
binddrivers
setclock load
FF >NIL: -0
mount newcon:
;
failat 11
run execute s:startupII
wait >NIL: t mins
path c: ram: add
assign c: rad:c
LoadWB
df0:c/mymenu
endcli
-------------------------------------------------------------------------
				STARTUPII
-------------------------------------------------------------------------

ares c:ares c:list c:cd c:type c:info c:asign c:makedir c:mount
ares c:more NOCHECK
makedir ram:t ram:env ram:clipboards
assign t: ram:t env: ram:env clips: ram:clipboards
mount speak: aux: pipe:
ares mount remove
ares assign remove
ares makedir remove
copy boot1(my df1 disk):tools/memacs ram:
setenv editor ram:memacs
;setenv copyflags=CQ (this command doesn't work. yet!????)
break 1 c
    -----------------------------------------------------------------------
    
    
    mark
    

Well, with all that copying going on, Thing's are gonna be slooow the first 
time up!


Some comments I can see:


>			STARTUP-SEQUENCE
> ----------------------------------------------------------------------------

> Addbuffers df0: 20
> c:setpatch >NIL:
> cd c:
> echo "A500/A2000...Release 1.3 Version 34.20*N"

I think if you CD RAM: and then preface all you commands with C:command_name
things will speed up a bit. Startup uses temp file's of some kind that go in
the default directory.


>if not exist rad:c
>	relabel drive rad: name ramdrive
>	makedir rad:c rad:s rad:system rad:expansion rad:l

You might look into DEFDISK (on the net here). It speeds up the system
logical  assigns later.


John

Re: .15

>I think if you CD RAM: and then preface all you commands with C:command_name
>things will speed up a bit. Startup uses temp file's of some kind that go in
>the default directory.

The startup-sequence (or any command file) only uses temporary files is
command file argument passing is used, or if there is a nested EXECUTE.
RUN EXECUTE doesn't count as a nest since another CLI is started to
handle the EXECUTE.

So, I don't think CD RAM: will help much here.

    Installing ARP, using ARES, and placing multiple commands on a line has
    helped quite a bit.  I placed an "IF/ELSE" conditional to prompt
    whether I want to load the RAD: or not, which allows more memory for
    animations and whatnot.  I am unable to see anything to speed up the
    copies to RAD:, though.
    
    
    mark