Using CONST & _RGB used together seem to error...

[SpriggsySpriggs]

It's a feature IF it is documented, notifies the user, and is clear in its explanation. It's a bug if the user reads the manual, uses it as it is written, and then receives an outcome that differs from the promised behavior. This is a bug until documented properly.

[SMcNeill]

It *is* the imagehandle, in all cases except CONST.

Remember, we have two different work flows here. 

CONST is done in the precompiler process.  It works *BEFORE* compile time and before runtime.  So you can't use any runtime values with it.
 
Image handles are usually gotten with _LOADIMAGE or _NEWIMAGE or _COPYIMAGE.  Those are all done at run-time, and not at compile time.

Ergo, CONST can *NOT* use image handles.  You have to specify a SCREEN HANDLE directly for it with _RGB.

But at runtime, it just makes more sense to use _RGB with image handles.  You point it to the handle you want and that's it.  No need to remember the screen mode or any such thing.  Handle alone is good enough, which makes 0 especially useful as image handle 0 can be a SCREEN 0 screen, or a 256 color screen, or a 32-bit screen.   

0 as an image handle is *the current screen*.

0 as a SCREEN MODE is... *a text screen 0*.

Those 0's aren't the same, and the behavior shifts with CONST to mimic that change in behavior with regards to _RGB.

So with _RGB, the extra parameter is:
With CONST, it's the SCREEN MODE.
Any other time (at run time), it's the IMAGE HANDLE.

0 for one is not the same 0 as for the other, and the command relies upon that distinction.

[Dav]

Well thanks for the explanation.  That's something I didn't know with CONST.

Appreciate all the replies.

- Dav