********* CanDo 1.60 stuff... ********* New Installation Procedure: Systems with less than 1 meg and/or only one floppy: CanDo needs at least 1 meg of ram and at least two floppies or a hard drive. You will need about 3 meg of free space on your hard drive to successfully install the software. AmigaDos 1.3 Systems with 1 meg or greater and two floppies: Simply duplicate all three CanDo diskettes. Reboot you system but instead of using your normal workbench diskette boot off the CanDo Program diskette. Once you have rebooted with the CanDo Program diskette you will want to delete the three files "Installer", "Install-ToHardDisk" and "Install-ToFloppy20", this will give you about 200k worth of workspace on your boot disk. You might want to make multiple copies of this boot disk and store different projects on each one. That way to switch between projects you simply reboot your system with that project's boot disk. As for the CanDo Extras disk copy that you made, you will need to leave that in your second drive. CanDo will need this disk available while it is running. NOTE: when you duplicate the three CanDo diskettes you must rename them back to their original disk names. CanDo will look for things on those diskettes by the name of their disk. AmigaDos 2.0 Systems with 1.5 meg or greater and two floppies: After booting the system with your 2.0 Workbench disk, duplicate all three CanDo diskettes (renaming them back to the correct names). Then insert your copy of the CanDo Program diskette into one of your floppy drives. Double click on the disk icon. Once the diskette's window opens up you should click on the icon named "Install-ToFloppy20". This program will then walk you through the installation procedure. Once you are finished, reboot your system with that CanDo Program diskette. You should then delete three files: "Installer", "Install-ToHardDisk" and "Install-ToFloppy20", this will give you about 200k worth of workspace on your boot disk. You might want to make multiple copies of this boot disk and store different projects on each one. That way to switch between projects you simply reboot your system with that project's boot disk. As for the CanDo Extras disk copy that you made, you will need to leave that in your second drive. CanDo will need this disk available while it is running. NOTE: when you duplicate the three CanDo diskettes you must rename them back to their original disk names. CanDo will look for things on those diskettes by the name of their disk. Hard drive systems (AmigaDos1.3 or 2.0) with 1 meg or greater: After booting your system from the hard drive, insert the CanDo Program diskette into one of your floppy drives. Double click on the disk icon. Once the diskette's window opens up you should click on the icon named "Install-ToHardDisk". This program will then walk you through the installation procedure. NOTE: When running under AmigaDOS 2.0 with a hard drive we recommend your system have at least 1.5 meg of RAM. New ToolTypes: AutoBackToBrowse={logical} ; when we go back to mainpanel do we go back to browse automagically ; defaults to= not set ; if not set = NO AutoIndent={logical} ; This allows you to turn on and off the auto-indenting feature of the ; script editor. ; defaults to= not set ; if not set = YES BigEd={logical} ; adds 5 lines of text and two more editor tool holes in the tool bay. ; defaults to= not set ; if not set = NO ButtonBeep={soundfilename} ; if this is filled in then when ever you create a new button CanDo ; will automagically generate a OnClick script with a PlaySound ; using the give soundfilename. ; defaults to= not set ; if not set = nothing is generated CopyCommand={pathfile} ; used in various operations ; defaults to= not set ; if not set = "Copy" DeleteCommand={pathfile} ; used in various operations ; defaults to= not set ; if not set = "Delete" DocumentBeep={soundfilename} ; if this is filled in then when ever you create a new document object, ; CanDo will automagically generate a OnClick script with a PlaySound ; using the give soundfilename. ; defaults to= not set ; if not set = nothing is generated FieldBeep={soundfilename} ; if this is filled in then when ever you create a new field, CanDo ; will automagically generate a Select script with a PlaySound ; using the give soundfilename. ; defaults to= not set ; if not set = nothing is generated FixedPointSize={logical} ; This will make the font requester disable scaled fonts under 2.0x. ; No means that scaled fonts are available ; Yes means only fonts/sizes that really exists on disk are available ; defaults to= not set ; if not set = YES under 1.3x and NO under 2.0x KeyBeep={soundfilename} ; if this is filled in then when ever you create a new key object, CanDo ; will automagically generate a OnDown script with a PlaySound ; using the give soundfilename. ; defaults to= not set ; if not set = nothing is generated LayOutLeading={0-10} ; used by the layout tool from ProPack. This provides an extra pixel ; (or more) between the lines rendered by the LayOut tool. ; defaults to= not set ; if not set = 1 MaxHelpEvents={1 to 100} ; when remembering past help subject how far back to we record. ; 1 would mean don't bother recording history. the larger the ; number the more memory would be needed. ; defaults to= not set ; if not set = 25 MenuTool={objtoolname} ; any object tool can have it into the new Tools menu. Up to 5 tools ; may be placed by having multiple lines of the MenuTool tooltype. ; defaults to= not set ; if not set = no menu appears NameDelimiter={single ascii character} ; In the 1.5 version of CanDo each new object was named 'Button#1', ; or some similar name, but in 1.6 the names have been changed to ; 'Button_1'. The reason for the change (other than to confuse you) ; was that when making database objects the '#' symbol caused problems ; with the created variable names. The '_' is not much of a change ; and will make creating database objects easier. Also under 2.0 ; of the operating system the '_' character is now used in the ; BumpRevision() function, we use the function for duplicating objects. ; If you want you can change the character now to whatever you like. ; defaults to= not set ; if not set = "_" ObjectBeep={soundfilename} ; if this proves to be a valid 8svx sound file then this tooltype will ; act as if you had all four tooltypes: ButtonBeep, KeyBeep, FieldBeep ; and DocumentBeep filled in with the same soundfile. ; defaults to= not set ; if not set = nothing is generated RenameCommand={pathfile} ; used in various operations ; defaults to= not set ; if not set = "Rename" SampleWindow={logical} ; If this is yes then the font and border requesters open a sample window. ; This is useful but will take a little more memory for these requesters. ; defaults to= not set ; if not set = YES SaveMethod={0|1|2} ; 0 = same as old way ; 1 = copy old file to xxx.bak, save new file, if successful delete ; the old file xxx.bak. ; 2 = same as way #1 except we will not delete old file ; defaults to= not set ; if not set = 0 Changed ToolTypes: IconDefaultTool={pathfile} ; if cando creates a deck icon, this will be its default tool. ; defaults to= "C:DeckRunner" ; if not set = "DeckRunner" <- used to default to "C:DeckRunner" ; the reason for the change to that deckrunner can now be anywhere ; in the workbench's path which automagically includes "C:" Changed ObjectTool: ARexx ObjectTool The ARexx tool will now allow for a empty string to be used for the message that it is waiting for. If an empty string is given then all messages that reach this object will be handled. In this case the first word of the message will not be parsed off and you can do it your self in the ARexx object script. The primary problem with this method of trapping arexx messages is that if there are any other ARexx object looking for specific message they have to be before (in the ARexx object list) this 'Catch All' object or they will never be seen. Menu ObjectTool There has been constant confusion about the label in menus since we release CanDo. The label in the text/font requester is and always has been the label printed in the menu bar. This is just like the label in text buttons. The confusion is caused by the fact if you never specify a menu label we default to using the object name. So what we have done is this (listen carefully). 1. If you are creating an item (via Add) AND you do not specify a label THEN the label will default to the object name. 2. If you are editing an item AND change the object name AND the label matches the original object name (including case) THEN we change the label to match the new name. 3. If you select Paste or CopyOf AND if the label is the same as the objectname (including case) AND if the objectname is changed (ie. Copy of...) THEN the label will be changed. You really don't have to think much about this stuff because it works more naturally than the old system. XtraTools changes and additions: You will find a few new xtratools on the CanDo Examples diskette, also due to space considerations we have moved the RightMouseButton and MenuRender tools from the CanDo Extras diskette to the CanDo Examples diskette. The installer program will move tools in the MoreXtraTools drawer on the Examples diskette into the XtraTools directory for you, but if you are running from a floppy only system you will have to rearrange the CanDo Extras diskette's XtraTools drawer yourself. There are two new xtratools: GamePort and Proportional. GamePort XtraTool: The gameport tool allows you to attach scripts to the actions of the joystick or mouse attached to the 2nd gameport of your Amiga. The object's definition requester lets you specify either mouse input or two types of joystick input. These object events operate as follows: Mouse - When the mouse icon is selected, your script will execute based on the conditions defined in the "Triggers..." section. The coordinates for X and Y Movement, in this case control the number of of mouse movement pulses or units for which to wait before actually causing your script to execute. The "Jiffies" field is used to cause your script to execute every 'n' jiffies (a jiffy is 1/60 of a second), for continual analysis of the current mouse position. We suggest that most applications use zero in this field so that scripts execute only when the mouse is moved. Joystick - The gameport object supports any Amiga compatible joystick or hardware that simulates one. The "Freedom..." object requester lets you select either 4 or 8 discrete directions to activate your script. Two styles of input may be selected. The first style (enabled by highlighting the upper joystick icon) will cause your script to execute repeatedly as long as the stick is held in any direction other than center. The second style (lower joystick icon) will only activate your script when its state changes. The "Jiffies" field may be used as with the mouse to continually poll the joystick for its current position. The "Button..." selection may be used to specify how buttons will execute your script. You may choose to execute your script when a button is pressed, released, either, or ignore any button presses. Note that both 2 and 3(AmigaDOS2.0) button mice and 1, 2, and 3 button joysticks are supported. Once you've specified the attributes of the gameport object, you have four arguments passed to you in your script. They are as follows: ARG1 reflects the button status when a button action causes your event. FLAGS returned are: NONE, LEFT DOWN, LEFT UP, MIDDLE DOWN, MIDDLE UP, RIGHT DOWN, RIGHT UP Example: If a button did not cause your event then "NONE" will be returned in arg1 when your script executes. If the left button is pressed down then "LEFT DOWN" will be returned in arg1. Most popular joysticks with only one button will set the LEFT flag. ARG2 is the direction desciption of the joystick. This is inhibited to only 4 flags when the Freedom is set to four directions. FLAGS returned are: UP, UP RIGHT, RIGHT, DOWN RIGHT, DOWN, DOWN LEFT, LEFT, UP LEFT ARG3 and ARG4 contain relative movement information on how far the mouse/joystick has moved in the X (arg3) and Y (arg4) direction. Please refer to the decks on your CanDo Examples and Utilities Disk for an example implementation of the gameport object. Proportional XtraTool: The proportional tool allows to add slider like objects to your card. These can be your normal left/right or top/down sliders or two dimensional sliders like the 1.3 screen position preference tool. Adding proportional sliders to your application is similar to adding buttons. Sizing and positioning is the same. The slider may be defined as either an image or an "AutoKnob". To use an image for the slider you may specify a brush as you do for a normal button or menu. The "AutoKnob" option gives you a normal proportional slider like those used in many file requesters and lists. The size of the knob as it relates to its container is proportional to the data that it manipulates. You also have the option of having a system border around the slider area. Your proportional slider can be configured to slide horizontally, vertically, or both by selecting the corresponding "Freedom..." button. The slider can then be defined to return a range of values based on the integers you supply in the top, bottom, right and left fields. Initial position and size of the slider can be defined from the Freedom requester. Once you have created a slider, you may query its position with the GetPropPosition command. See it and other new scripting commands to set and retrieve various data regarding proportional sliders in the new command documentation. Also refer to the examples on the 3rd disk for a demo application. EditorTools changes and additions: We have added one additional editor tool: CoordinateBox. CoordinateBox EditorTool: This works just like the Coordinate tool that you already had but instead of returning simply a coordinate this returns both the coordinate and size of the dragged out box. Changed Commands/Functions/Variables: FileReadChars {FileReadBuffer}, , {charcount} [,HEX] ; if the HEX keyword is given then the read characters are converted ; into a hex string (see CharsToHex/HexToChars). FileWriteChars {FileWriteBuffer}, {text} [,{charcount} [,HEX]] ; if HEX is given then the text is assumed to be a hex string. the ; hex string is converted into a character string and written. you ; have to provide the charcount if you want to use the hex keyword. ; if charcount is MAXINTEGER then the whole text string is used so ; this is the easiest way of just writing binary info without knowing ; how long the string is. New Commands/Functions/Variables: ClosePendingWindow In certain cases subwindows will not close after their card quits. This command will force the subwindow, that may be pending, to close. This command is safe to call at any time so use it as much as you want. GetPropPosition {ObjectName}, [,] This will retrieve a proportional object's positional values. GetPropRange {ObjectName}, , ... ...[,, ] This will retrieve a proportional object's upper and lower range limits. GetPropVisibleRange {ObjectName}, [,] This will retrieve a proportional object's visible size. LoadPalette {FilePath} [,{PaletteBufferName} [,]] This will load only the palette part of a picture or brush. The resultant buffer can be used only by the ShowPalette command. See page 7-7 in the yellow manual for a for a full description of the load flags. SetPropPosition {ObjectName}, {HozPos} [,{VertPos}] This will set a proportional object's positional values. SetPropRange {ObjectName}, {LowHoz}, {HighHoz} [,{LowVert}, {HighVert}] This will set a proportional object's upper and lower range limits. SetPropVisibleRange {ObjectName}, {DisplayHoz} [,{DisplayVert}] This will set a proportional object's visible size. SetSystemRequesterTo WORKBENCH | NOWHERE | WINDOW ; this redirects the dos autorequester (the thing that ask for a specific ; disk to be inserted) to a specific place. ; WORKBENCH means that the requester should open on workbench (default) ; NOWHERE will turn off the requester (it won't open at all) ; WINDOW will cause the requester to open on the current window's screen. Let {hexstring}=CharsToHex( {string} ) Let {string}=HexToChars( {hexstring} ) ; these will convert a string into its equivalent hexstring and back ; again. the hex string will be exactly twice as long as the string. Let {hexstring}=IntegerToHex( {integer} ) Let {integer}=HexToInteger( {hexstring} ) ; this will convert a integer into its hex equivalent and back again. ; this convert to the minimum hex values (ie. no leading zeros). if ; you want the hex string with leading zero simply use the ; RightJustify() function. Let {address}=ScreenAddress Let {address}=WindowAddress ; these return integers that are the physical address your card's screen ; or window. Only really useful for 'C' or ASM programmers. ResizeWindow {NewWidth},{NewHeight} ; this will cause the current window to be resized. Bugs Fixed: 1: # vs NOT operator: On page 7-1 of the index it seems that the '#' symbol is the same as the 'NOT' operator. They are not the same! The '#' operator is like the '<>' not equal to comparison operator where as the 'NOT' operator is is a logical operator. Let Foo=27 If Foo # 27 Echo "Foo is not equal to 27" Else Echo "Foo is equal to 27" EndIf ..where as.. If Not ObjectState("Button#1") Echo "Button#1 is not on" EndIf 2: Early versions of CanDo 1.5 could not handle spaces preceding variable names correctly in some cases. This has been fixed. 3: In CanDo 1.0x the expression system let zero(0) be the same as a logical FALSE. Under CanDo 1.5 they were not the same. This bug also causes one(1) not be TRUE. This has been fixed, it works like CanDo 1.0x. 4: If you where reinstalling CanDo 1.5 into the same place as your old CanDo 1.0x then the installer would leave both the old routine object and editor tool. While the old object tool did not cause problems the editor tool would show up in the editor tool strip and when clicked on would cause a fatal error. The new installer will now remove these old tools if they exist. 5: The timer objects in CanDo 1.5 caused numerous, but seemingly unrelated, problems including: Clearing Integer Fields (including CanDo's), Preventing ARexx events from being seen, Preventing button events from being process in a timely fashion and generally causing general chaos. This has been fixed. 6: In certain PAL machines CanDo's mainpanel would slide too far up the user's screen. It now appears down where it is supposed to be. 7: If the user specifies alternative screen fonts under 2.0 the utilities would not adjust correctly. 8: Relocator utility was not creating a icon for its saved decks. 9: If an object did a showpicture, the objects do not refresh the first time. Every time there after the objects refresh correctly, strange. This bug has been fixed. 10: If you open a file, with the OpenFile command, in APPEND mode and the file does not exist system returns an error (Object Not Found). It was supposed to create the file in that case. It now does. 11: CanDo's filerequester was getting confused if the user given it relative path and/or filename in its tooltypes. 12: The old hard drive installer has been replaced and we now use the Commodore Standard Installer. 13: The color bars caused fatal errors in certain cases in 1.5. This has been fixed. 14: The Button object tool had problems with shape only buttons when dealing with highlight selection. 15: The Printer utility was forgetting its tabsize settings. 16: The BrushAnim Editor Tool was generating the Sync flag backwards. 17: The TrimString function was causing unpredictable memory munging. 18: Daily timers that were set to go off on a certain day of the week were going off everyday. 19: Under certain cases the Script Editor would generate very long lines and cause a fatal CanDo crash. 20: Various Dual Floppy problems have been fixed. 21: Strange mask and/or shape problems have been fixed. You may have noticed this will large images on buttons or with ShowBrush if you had transparent ON. 22: SetBrushAnimFlags no longer leave brushanims buffers in use. 24: Various memory leaks have been plugged. 25: InsertRecordNames leave a blank line like the rest of the Insert commands. 26: SetText and GetTextDimensions both suffered memory leaking problems. 27: FTXT documents that were multibound were not be looked for correctly. They will now be found if they are multibound to the deck application. 28: Under 2.0x your deck windows (if set up for workbench) were not following the Shanghai flags correctly (if you don't understand don't worry). 29: Your decks should now have 2.0x new look window borders and sliders when running under 2.0x. This may cause you to do some color problems but for the most part every deck we looked at appeared just fine. and various cosmetic bugs and help file have been corrected. ********* Original Errata to The Manual Supplement For CanDo v1.5 ********* This file contains all last minute changes and corrections to the manual supplement which came in this package. ********* Section 1 ********* Page 12, Under "New Shortcut Keys" The shortcut keys for 'CanDo screen to back' and 'CanDo screen to front' are incorrectly listed. They should read: Control-Shift-F9 - CanDo screen to back Control-Shift-F10 - CanDo screen to front ********* Section 2 ********* Page 5, Script Example under "ShutDownDeck - a utility..." This script example is incorrectly formatted and, as such, is difficult to understand. The correct formatting is as follows: Let count=1 ;initialize count to zero While count<10 ;loop until count becomes ten or greater PlaySound "CanDo:Sounds/DogBark.snd" Let cnt=cnt=1 ;we misspelled our count variable EndLoop ;we'll never end NextCard ;go to the next card ********* Section 3 ********* Page 2, Command Examples under "Parameters Passing Between Cards" The optional arguments need only be preceded by a comma in the "GotoCard" command line. The comma is not required for the FirstCard" command line or the subsequent similar commands. The list of command templates is shown properly below: GotoCard "CardName" [,Arg1,Arg2,...Arg10] FirstCard [Arg1,Arg2,...Arg10] LastCard [Arg1,Arg2,...Arg10] NextCard [Arg1,Arg2,...Arg10] PreviousCard [Arg1,Arg2,...Arg10] ********* Section 6 ********* Page 33, Under "Command: SetViewOffset , The sentence which reads, "If your window has menus, it may be necessary to use the Xtra Tool, MenuRender, to create a "Before Rendering Menus" script to set the view back to 0,0." is incorrect. The recommended procedure is to use GetViewOffset to determine the 'pre-menu rendering' position and to set them with SetViewOffset. Setting the view to 0,0 is not recommended.