Blitz Basic 2 basics

[Daedalus]

Originally Posted by amyren

In the docs these commands are mentioned LoadAnim, InitAnim, and NextFrame.
But so far just by adding this line will result in an error meaasage, "unable to free memory"
LoadAnim 0,"images/animtest.iff"
Is there an example of how to do this in a system friendly way?

I don't think the standard animation commands are particularly system-friendly. You could try using the LoadShape command to load the frames if there aren't too many frames, then blitting the frames yourself as needed. Loading large shapes in itself has its own problems however.

I do remember the standard commands working for me many years ago, though it was very picky about the format. Try saving the animation as a different format if possible. Do you have a bitmap set up already? BitmapToWindow can then be used to display the bitmap the animation is rendering to in a window. As previously mentioned, palette information will have to be set for the screen for this to look right.

It might be worth looking at the RIAnim library of commands. I haven't used it, but apparently it supports other animation formats, and seems a bit more useful (uses fast RAM and can blit the animation at any position on a bitmap for example).

In my program I have the main program window (window 0) and then I do have several other windows in different sizes that will pop up. But maximum there will be two windows open at once.
So I think I could get away with using only Window 0 and Window 1 used in my program, as long as those extra windows only are used to display text.
Or would this be considered bad practice?

I'm not sure what the relevance of showing text only is. Each window you open needs to have its own ID that's unique to every other window you have open. If you only ever have two windows open, you can use IDs 0 and 1. But if there are lots of different windows your program can handle, that wouldn't be particularly good practice as it can lead to confusion later on. A better approach would be to have a separate ID for each window, regardless of whether other windows are open at the same time. For example, always use ID 0 for the main window, ID 3 for the Preferences window, ID 5 for the Help window, and so on.

Even better practice would be to declare some constants, and use them instead of just numbers for the ID. This will make your code far more readable in the future, and will help to reduce the chances of bugs even further. For example:

#MainWin = 0
#DebugWin = 1
#PrefsWin = 2
#OutputWin = 5

And then, later on in your program you can use them like this:

WindowOutput #OutputWin

If EventWindow = #PrefsWin
  NPrint "Prefs Window was used"
End If

Then I wonder about the compiler settings. When my program is finished, should one finetune those settings for numbers of objects, windows, anims etc. to fit exactly the number used in the program. Would this reduce the memory requirements for the program?

Not by any amount likely to be worth the time taken to change all the numbers. Basically, each of those items is set up as an array of the possible objects, so reducing the limit reduces the size of the array. But that's only going to be a few hundred bytes at most I suspect, so unless you're desperate for that few bytes (in which case I'm impressed that you're running so close to the limit), I wouldn't bother.

[amyren]

Originally Posted by Daedalus

I don't think the standard animation commands are particularly system-friendly. You could try using the LoadShape command to load the frames if there aren't too many frames, then blitting the frames yourself as needed. Loading large shapes in itself has its own problems however.

I do remember the standard commands working for me many years ago, though it was very picky about the format. Try saving the animation as a different format if possible. Do you have a bitmap set up already? BitmapToWindow can then be used to display the bitmap the animation is rendering to in a window. As previously mentioned, palette information will have to be set for the screen for this to look right.

I think I will skip the animations for now. I just thought it would be cool to have anims instead of some of the images, but I do want to keep this OS friendly.

I'm not sure what the relevance of showing text only is.

Perhaps it just a case of bad program structure
This program started as a text adventure kind of game, just that I wanted to add a GUI to it. That is the main window of the program, showing some short messages, navigation and a few other buttons, inventory and active objects.
And then I added some images to this, so that window is now more than 500 pixels wide. I was trying to make sure that the program could work on screens from 640x512 pixels, so to make room for the longer messages I do use additional windows.

Not by any amount likely to be worth the time taken to change all the numbers. Basically, each of those items is set up as an array of the possible objects, so reducing the limit reduces the size of the array. But that's only going to be a few hundred bytes at most I suspect, so unless you're desperate for that few bytes (in which case I'm impressed that you're running so close to the limit), I wouldn't bother.

I am not on the limit, but I was thinking I would make the program run on as low requirements as possible, so then there could be setups where just a few kilobytes of free memory might do a difference. I want to compile one version (without images) on Blitz2, that should run on Workbench1.3 and up. But if its only a few bytes, it probably doesnt matter.

A different matter: As discussed earlier, the executable size is reduced when compiling many times in a row, even when "Make smaller code" is selected.
In my case it starts at 784kb and after nine compiles is reduced to 636kb.
When Compiling, I usually use the keyboard combination Amiga+E, and Amiga+O to do this quickly.
But in the Compiler Menu, there is another selection, "Make minimized executable". If I use that, the executable will be dramaticly reduced, down to 450kb.
I wonder, is it just the time it takes to compile that is the downside of having the small executable, or is there another catch here?

[Daedalus]

Originally Posted by amyren

Perhaps it just a case of bad program structure
This program started as a text adventure kind of game, just that I wanted to add a GUI to it. That is the main window of the program, showing some short messages, navigation and a few other buttons, inventory and active objects.
And then I added some images to this, so that window is now more than 500 pixels wide. I was trying to make sure that the program could work on screens from 640x512 pixels, so to make room for the longer messages I do use additional windows.

Ah, I see. That's no problem, I was just confused about whether you were trying to treat a window differently because it just contained text.

I am not on the limit, but I was thinking I would make the program run on as low requirements as possible, so then there could be setups where just a few kilobytes of free memory might do a difference. I want to compile one version (without images) on Blitz2, that should run on Workbench1.3 and up. But if its only a few bytes, it probably doesnt matter.

It might be worth experimenting with to see just how much RAM you save...

A different matter: As discussed earlier, the executable size is reduced when compiling many times in a row, even when "Make smaller code" is selected.
In my case it starts at 784kb and after nine compiles is reduced to 636kb.
When Compiling, I usually use the keyboard combination Amiga+E, and Amiga+O to do this quickly.
But in the Compiler Menu, there is another selection, "Make minimized executable". If I use that, the executable will be dramaticly reduced, down to 450kb.
I wonder, is it just the time it takes to compile that is the downside of having the small executable, or is there another catch here?

Yep, the only downside I know of is the time it takes, as that option makes several passes at the compile, probably similar to you selecting Compile again and again.

[amyren]

Is there a GT equivalent to MenuColour?

If I use GTMenu I notice that my menus will show black text on black colour on the WB screen.

[Daedalus]

This is because the menus are using the old OS2 look, but the text colour is coming from the screen's properties, meaning they both end up black. You need to turn on the New Look flag when opening the window to avoid this. Add #WFLG_NEWLOOKMENUS to the Window's flags when you open it and it should be a white background.

[amyren]

Thanks, that did work fine.
Do you happen to know the value for the #WFLG_NEWLOOKMENUS ?

I did look at the amiblitz.de programmers guide, and many of those other window flags are listed with their value, but this one was not listed. Probably due to that the guide seem to be a copy of the blitz 2.1 manual, and not updated for AmiBlitz.

[Daedalus]

Originally Posted by amyren

Thanks, that did work fine.
Do you happen to know the value for the #WFLG_NEWLOOKMENUS ?

It's $200000, though I had to look it up. All these values are standard values used by the OS. If you look at the intuition include file from the Amiga developer material, it includes all the possible values, including the ones listed in the Blitz manual and newer values introduced later. You can see the include online here (scroll down a little or search for the WFLG_NEWLOOKMENUS string). It's marked as a 3.0 and above value, so it won't have any effect on 2.0, but that's ok since 2.0 has reversed colours in its screen bar and menus as standard.

Using the values directly is a little old-fashioned, though that is the approach taken by the Blitz manual. It will make your code a little harder to understand later on when you can't remember which value corresponds to what feature. The Autodocs from the development kit also include the various constants that you can use, along with a description of their function. You can read them here for window opening flags, and in general from http://amigadev.elowar.com/. I would recommend having a look

I did look at the amiblitz.de programmers guide, and many of those other window flags are listed with their value, but this one was not listed. Probably due to that the guide seem to be a copy of the blitz 2.1 manual, and not updated for AmiBlitz.

Yeah, it's literally just a HTML conversion of the AmigaGuide version of the Blitz manual. There are many values missing from the manual, even for older 2.0-era functions. It appears they just picked a handful of the most common values to list, rather than filling the manual with long lists of values that most users wouldn't use (or, even better, listing the constants instead). That flag was introduced with OS 3.0, which Blitz 2.1 supports, so the constant was definitely known at that time, even if it wasn't listed. AB3 did update the amigalibs.res file to include constants from OS 3.5 however.

I would recommend bookmarking the autodocs so you can have a read of them when you need to. There's a whole host of extra information that you might find useful, even though it's primarily aimed at C coding.

[amyren]

Thanks, thats a lot of useful reading there. Although a bit confusing to navigate in the material if you don't know where to look.

But I did learn one thing new. I did read about that GIMMEZEROZERO flag earlier, and did understand that it would prevent the window borders from being overwritten. So I did use that flag ( $400 ) for my windows.
Now I see that flag is the reason for that my gtgadgets does not use the same x,y reference as wlocate x,y does.
If $400 is set, then 0,0 for a GTButton moved just as much from the inner window border as the border thickness.
On AmiKit X there are quite wide borders, and then the button will be offset 8,30 from the inner border.
I don't quite see the purpose of this offset, and I wonder if this is an unwanted sideeffect of GIMMEZEROZERO ?


Is there a known problem with gadtools in the 2.x kickstartrom and BlitzBasic?
I can get my program to run on all setups I've tried, from WB1.3 and up to 3.9, and even OS4.1 classics and MorphOS, exept for if I use kickstart v2.04 or v2.05.
It will run on WB2.1, but only if I use the 3.0/3.1 rom.
On kick 2.x it will freeze the system as soon as the first window using gadtools is opened.

[Daedalus]

Originally Posted by amyren

Thanks, thats a lot of useful reading there. Although a bit confusing to navigate in the material if you don't know where to look.

Yeah, they can be a bit of a black hole when you're not used to navigating the autodocs, but there's a search function on the front of that website (amigadev.elowar.com) that works reasonably well, and if you use the constant values and don't need to know the actual numbers involved, you can ignore the includes, which are often the most daunting bits to trawl through.

But I did learn one thing new. I did read about that GIMMEZEROZERO flag earlier, and did understand that it would prevent the window borders from being overwritten. So I did use that flag ( $400 ) for my windows.
Now I see that flag is the reason for that my gtgadgets does not use the same x,y reference as wlocate x,y does.
If $400 is set, then 0,0 for a GTButton moved just as much from the inner window border as the border thickness.
On AmiKit X there are quite wide borders, and then the button will be offset 8,30 from the inner border.
I don't quite see the purpose of this offset, and I wonder if this is an unwanted sideeffect of GIMMEZEROZERO ?

Now, as for the gadget positioning, this could indeed be classed as a bug, though I suspect it may have been done deliberately. If you compile with Blitz 2.1, the gadgets will be in the correct location, so someone has "fixed" it in the transition to AmiBlitz 3 so that GadTools gadgets have the window boarders added to their positions automatically. This means that for GadTools windows you don't really need to use the GIMMEZEROZERO flag at all (and there are advantages to that too - using it takes more memory and IIRC is slightly slower than standard windows, and capturing a GZZ window with SGrab will save an image without the border), but results in a disagreement between coordinates used for things like drawing graphics and text. It's a little extra work, but using a non-GZZ window is probably a better approach in general.

Is there a known problem with gadtools in the 2.x kickstartrom and BlitzBasic?
I can get my program to run on all setups I've tried, from WB1.3 and up to 3.9, and even OS4.1 classics and MorphOS, exept for if I use kickstart v2.04 or v2.05.
It will run on WB2.1, but only if I use the 3.0/3.1 rom.
On kick 2.x it will freeze the system as soon as the first window using gadtools is opened.

Yes, well sort of. I don't think it's a Blitz-specific problem, but a general OS one. GadTools was heavily overhauled between OS2 and OS3, and since gadtools.library resides in Kickstart, the Workbench version used has little effect. There are certain gadgets that behave differently under KS2, and some that simply don't exist at all. In addition, KS2 requires some gadget IDs to be reserved internally, so your first gadget ID should be 50 if you want to be safe under KS2. This might mean increasing the maximum object count for GadTools in the compiler settings to avoid crashes further down the line.

I'd suspect your issue is in there somewhere. I'm not familiar with the GadTools add-on for OS1, but I suspect it's based on the KS3 version if your code works fine.

[amyren]

Originally Posted by Daedalus

Now, as for the gadget positioning, this could indeed be classed as a bug, though I suspect it may have been done deliberately. If you compile with Blitz 2.1, the gadgets will be in the correct location, so someone has "fixed" it in the transition to AmiBlitz 3 so that GadTools gadgets have the window boarders added to their positions automatically. This means that for GadTools windows you don't really need to use the GIMMEZEROZERO flag at all (and there are advantages to that too - using it takes more memory and IIRC is slightly slower than standard windows, and capturing a GZZ window with SGrab will save an image without the border), but results in a disagreement between coordinates used for things like drawing graphics and text. It's a little extra work, but using a non-GZZ window is probably a better approach in general.

It actually does the same positioning offset if when compiled with Blitz2. But I have now removed GZZ in my source for both ab3 and bb2.

I'd suspect your issue is in there somewhere. I'm not familiar with the GadTools add-on for OS1, but I suspect it's based on the KS3 version if your code works fine.

I did increase all those ID by 50 and compiled it in Blitz2, but it still freeze on ks2. But thanks anyway. It was worth a try, but I don't think I will use to much time on that issue.

[Daedalus]

Oh, that's odd, because it's a difference I've had to compensate for when moving my code from AB3 back to BB2. I guess there might be a difference in the command library versions we have then - perhaps it was "fixed" in a previous BB2 update that I don't have installed...

Hmmm, sorry about that. The best I can suggest is to get familiar with the various tags that GadTools uses, as some are OS3-specific, and it's possible that there's one that's applied automatically by Blitz that's tripping it up. Try stripping it down to just one gadget, see if it works, and start adding back the items one by one until you find the problem, and maybe that can offer some clues as to what's going wrong.

[amyren]

Originally Posted by Daedalus

Oh, that's odd, because it's a difference I've had to compensate for when moving my code from AB3 back to BB2. I guess there might be a difference in the command library versions we have then - perhaps it was "fixed" in a previous BB2 update that I don't have installed...

Hmmm, sorry about that. The best I can suggest is to get familiar with the various tags that GadTools uses, as some are OS3-specific, and it's possible that there's one that's applied automatically by Blitz that's tripping it up. Try stripping it down to just one gadget, see if it works, and start adding back the items one by one until you find the problem, and maybe that can offer some clues as to what's going wrong.

At least it is better when AB3 and BB2 does it the same way. There is less to change in the source code when testing every revision on both blitz3 and blitz2.
I did install some update to my blitz2 installation, but I can not remember where I got them from. That did fix the issue I had with the GTButtons did not update automaticly when setting GTEnable /GTDisable. gtdisable

For the OS2 thing, I only use gtstrings and gtbuttons in that window. I guess I can make two small programs just with a single button and another with a single string to see if they freeze as well.

Now, regarding that animation issue mentioned earlier.
I did not need a real advanced animation, just wanted to have something moving on certain events to make it look cooler.
First i did this variant, which did work well on my test system.
Notice I did use image 0 for every frames, because I asumed it would save memory.

So here is my attempt at a system friendly "animation"

Repeat
  If image_Load{0, "images/frame_1.iff"}
    image_Blit{0, 360, 315}
  EndIf
  VWait 10
  If image_Load{0, "images/frame_2.iff"}
    image_Blit{0, 360, 315}
  EndIf
  VWait 10
  If image_Load{0, "images/frame_3.iff"}
    image_Blit{0, 360, 315}
  EndIf
  VWait 10
  VWait
  If image_Load{0, "images/frame_4.iff"}
    image_Blit{0, 360, 315}
  EndIf
  VWait 10
Until MButtons = 1

Bu then I tested it on a slower system (winuae, A500/A1200 speed) and found that this was to slow.

Then I did this, since it would be faster to load all frames into memory before displaying them.
I know those nested if's looks a bit dubious, but that was to avoid problems if any of the files
refused to load. This did play much faster on the slow system.

If image_Load{0, "images/frame_1.iff"}
  If image_Load{1, "images/frame_2.iff"}
    If image_Load{2, "images/frame_3.iff"}
      If image_Load{3, "images/frame_4.iff"}
        Repeat
          image_Blit{0, 360, 315}
          VWait 10
          image_Blit{1, 360, 315}
          VWait 10
          image_Blit{2, 360, 315}
          VWait 10
          image_Blit{3, 360, 315}
          VWait 10
        Until MButtons = 1
      EndIf
    EndIf
  EndIf
EndIf

[Daedalus]

Yep, that nested setup looks fine, though you can't really do much else when the loop is running. In some cases that's fine, but just in case you wanted to incorporate the animation in your main loop, you can use a frame counter that updates every frame, and then check it in the main loop:

At the start of your program:

SetInt 5
   framecount.w + 1
End SetInt

And then, the framecount variable will be increased by 1 every frame. Now, in your main loop you can do something like this:

If framecount >= 10
  framecount - 10
  image_Blit{currentframe.w, 360, 315}
  currentframe + 1
  If currentframe > 3 Then currentframe = 0
End If

Subtracting 10 from the counter instead of simply setting it to 0 will mean that if you ever miss one because you're doing something else, it will catch up with the original timing.

[amyren]

It took me a moment before I understood what that code was doing. I did not know anything about interupt codes and vertical blanking so I had to look that up in the blitz manual. But it looks good.

But for that to work, the main loop have to run continuously and uninterupted.
Wouldn't that take a lot of CPU and slow other things down?

And I use waitevent in my main loop, so the loop will halt while it waits for user input (to press a button in the main window).
I guess to be able to use that routine in my program, I will need to find another way to detect those button or menu events.

[Daedalus]

Yes, you're right, it's not a solution for every situation, just an alternative to bear in mind. It all depends on what your main loop is doing. Sometimes main loops can run continuously, e.g. when your program does some sort of processing, or in the case of most games. You can limit the amount of CPU time your program uses in a loop like that with VWait, or the Delay_ system call.

Another friendly alternative for programs that do use WaitEvent, is to add the #IDCMP_INTUITICKS flag to your window's IDCMP list. This triggers an event roughly every 0.1 seconds, making it useful for animation and other tasks in a program loop that uses WaitEvent, however it will only work while the window is active.

[Dan]

Hello, i would shorten the code by doing something like this:

For x=0 To 3
	If image_load{x,"images/frame_"+Str$(x)+".iff"} = 0 Then Goto donothing
Next 

Repeat
	For x=0 To 3
		image_Blit{x, 360, 315}
		VWait 10
	Next
Until MButtons = 1
.donothing:

P.S. the above would work on BlitzBasic for the PC. (i'm not familiar with the Amiga BB syntax)

[amyren]

Originally Posted by Daedalus

Yes, you're right, it's not a solution for every situation, just an alternative to bear in mind. It all depends on what your main loop is doing. Sometimes main loops can run continuously, e.g. when your program does some sort of processing, or in the case of most games. You can limit the amount of CPU time your program uses in a loop like that with VWait, or the Delay_ system call.

Another friendly alternative for programs that do use WaitEvent, is to add the #IDCMP_INTUITICKS flag to your window's IDCMP list. This triggers an event roughly every 0.1 seconds, making it useful for animation and other tasks in a program loop that uses WaitEvent, however it will only work while the window is active.

It turns out VWait does actually use a lot of cpu time, but Delay_ apears to use very little cpu.
I just tested using Delay_ in place of VWait in my nested loop example, and there was a big difference. Also testet adding VWait 1000 into a program, and while that was processing I could hardly move a workbench window around. The same test with Delay_ 1000 and the system was very responsive.
I just need to test Delay_ on other systems to check if its system friendly, and then I will replace all vwaits.

For the waitevent, I asume I just can use Event instead of waitevent if I want the mainloop to cycle without stop.
It did not seem to be to CPU intensive. And to make things smoother, I could add a Delay_ 2 into the mainloop.

Regarding that animation, as you can see from my example above, I use MButtons to stop the animation and continue the program. That works well enaugh, but MButtons will only detect this if the mouse is inside the window, and not hitting a gadget. This is in the main window, and the user might try to press buttons to continue, and then it will seem like the program is stuck in that anim loop.

I don't know if there is a command to detect general window mouse activity, so I tried this, which seem to work. It will detect menu access, gtgadgetbuttons, closewindow as well as presses in empty areas in the window. It also detects presses in the gttext gadgets, but for some reason only double-clicks.

animstop = false
Repeat
  ev.l = Event
  image_Blit{0, 360, 315}
  Delay_ 10
  image_Blit{1, 360, 315}
  Delay_ 10
  image_Blit{2, 360, 315}
  Delay_ 10
  image_Blit{3, 360, 315}
  Delay_ 10
  If MButtons = 1 Then animstop = True
  If ev > 0 Then animstop = True
Until animstop

Another question, unrelated to the subject above, but something I have wondering about for a while. I searched for a windowflag to add scrollbars to a window, but can not find it. Is this not supported by Blitz?
The particular usage is if I want to display more text than the size of a window allows.

[amyren]

Originally Posted by Dan

Hello, i would shorten the code by doing something like this:

For x=0 To 3
	If image_load{x,"images/frame_"+Str$(x)+".iff"} = 0 Then Goto donothing
Next 

Repeat
	For x=0 To 3
		image_Blit{x, 360, 315}
		VWait 10
	Next
Until MButtons = 1
.donothing:

P.S. the above would work on BlitzBasic for the PC. (i'm not familiar with the Amiga BB syntax)

Thank you. It should work on Amiga Blitz as well.
That would save even more code if I decide to add more frames later.
I could use that, but I would like to add some check that all the frames are loaded before trying to blit them.

loadfail.b = false
For x=0 To 3
	If image_load{x,"images/frame_"+Str$(x)+".iff"} 
	else loadfail = true
	endif
Next
if loadfail = false
	Repeat
		For x=0 To 3
			image_Blit{x, 360, 315}
			Delay_ 10
		Next
	Until MButtons = 1
EndIf

[Daedalus]

Originally Posted by amyren

It turns out VWait does actually use a lot of cpu time, but Delay_ apears to use very little cpu.

VWait's CPU usage depends on how long your loop takes to execute. It puts your program asleep until the end of the current frame, but if the loop takes close to 1/50th of a second (or 1/60th on an NTSC machine), it will effectively be a busy loop. Delay_ will wait for one tick (1/50th of a second) from the moment it is executed, so it will give much more CPU time back to the rest of the system.

I just tested using Delay_ in place of VWait in my nested loop example, and there was a big difference. Also testet adding VWait 1000 into a program, and while that was processing I could hardly move a workbench window around. The same test with Delay_ 1000 and the system was very responsive.

That's interesting, because it shouldn't take CPU time in situations like that... I wonder if that's another thing that's been "fixed" over the years - I must check it out!

I just need to test Delay_ on other systems to check if its system friendly, and then I will replace all vwaits.

It's definitely system friendly It's part of the dos.library API

For the waitevent, I asume I just can use Event instead of waitevent if I want the mainloop to cycle without stop.
It did not seem to be to CPU intensive. And to make things smoother, I could add a Delay_ 2 into the mainloop.

Yep, Event is the same as WaitEvent, except that it returns a 0 if there's no event waiting instead of waiting for one to arrive. In itself it's not CPU intensive, it's whatever else happens that eats up the CPU time in a busy loop.

Regarding that animation, as you can see from my example above, I use MButtons to stop the animation and continue the program. That works well enaugh, but MButtons will only detect this if the mouse is inside the window, and not hitting a gadget. This is in the main window, and the user might try to press buttons to continue, and then it will seem like the program is stuck in that anim loop.

I don't know if there is a command to detect general window mouse activity, so I tried this, which seem to work. It will detect menu access, gtgadgetbuttons, closewindow as well as presses in empty areas in the window. It also detects presses in the gttext gadgets, but for some reason only double-clicks.

There are a couple of things that might help. Your code is breaking the loop whenever *any* relevant event is detected, and not necessarily a mouse click. If you're only ever going to run on native hardware, you could check the Joyb() function on port 0, it will return 1 if the left button is pressed, 2 if the right is pressed and 3 if both are pressed (bits 0 and 1 for left and right respectively). The specific mouse event (#IDCMP_MOUSEBUTTONS) will only trigger inside the window, which is probably why MButtons fails elsewhere. To make it work with gadgets, I would say your best bet is to not blit-wait-blit-wait for the entire animation, but blit each frame in the main loop as it runs. That way, you never take more than one frame to react to an event, stopping the animation if necessary.

Another question, unrelated to the subject above, but something I have wondering about for a while. I searched for a windowflag to add scrollbars to a window, but can not find it. Is this not supported by Blitz?
The particular usage is if I want to display more text than the size of a window allows.

There's no easy way to do that in Blitz unfortunately. You can use the old-style Intuition gadgets to create a prop gadget and attach it to the window border, but it might not look as pretty as it should. There's a thread here about adding scrollbars that includes some source that would do the trick. It's C, but you can hopefully see the general steps required - mostly manually dealing with the gadget's attributes, which can be done with GTGetAttrs and GTSetAttrs. Now, I have a niggle in the back of my mind about one of those commands not being supported under KS 2... Sorry I can't be of more help there, but it's not something I've actually done myself.

Originally Posted by amyren

loadfail.b = false
For x=0 To 3
	If image_load{x,"images/frame_"+Str$(x)+".iff"} 
	else loadfail = true
	endif
Next
if loadfail = false
	Repeat
		For x=0 To 3
			image_Blit{x, 360, 315}
			Delay_ 10
		Next
	Until MButtons = 1
EndIf

Yes, this is the way I would do it too regarding loading. The code Dan posted would avoid blitting the shapes if they weren't loaded, but would also skip anything else happening in that loop. Your method allows the rest of the program to work if necessary (and avoids a Goto, which is generally a good thing...)

[amyren]

Regarding my previous problem that my program did crash when run on kickstart 2.x, I now figured out the problem. As Daedalus mentioned, it does have something to do with the gadtools acting differently in kick2.x.

At the beginning of my program there are some buttons defined, and by default some of these are disabled by using eg. GTDisable 0,21
Furtther down in the program the gtlist is attached to the window, and this did work fine exept in kick2.x.

The solution was simple, just move the GTDisable lines below after the gtlist is attached and it now runs under kickstart 2.x systems as well.

My gadget ID's are still below 50, but that did not cause any problems so far.