I already bypass the Intuition checkmark by setting the window checkmark to null.image which draws nothing and then draw my own checkmarks.

The reason I did this was that Intuition insists on drawing the checkmarks next to the left edge and I want to be able to have icons down the left instead.  So the checkmark had to be able to move over when there were icons present.

I'm currently thinking on the best way to take over greater control.
Normally intuition won't talk to the menu items until they need to change between selected or unselected or change check status.  When this happens it tells the menu items to draw themselves.

Mind you intuition stupidly, when the check status changes, tells the menu item to redraw itself first then updates the check status before drawing the checkmark.  Unfortunately this means that the information we have at hand may be wrong so when I draw the checkmarks the state I read may or may not be the final state.
It is an unnoticed bug until you try to do what I did.
Anyhow I created a work-a-round at a tiny data cost.

But if I do what I want to do that shouldn't matter anyway.
What I need to do is make intuition constantly talk to the menu items everytime the mouse moves or the user clicks.  I think I can do this by having two menu items that are both toggle checked.  One menu item will be a 1x1 pixel and the other menu item will be the full menu size.  But... this will alternate.  So menu item 1 will be 1x1 pixel under the mouse pointer and menu item 2 will be full menu size.  But when user moves mouse off 1x1 item 1 and over item 2 then  item till will relocate to where mouse is and change to 1x1 pixel and item 1 will then become full menu size at menu (0,0).

It will depend upon whether intuition uses the hittest method on the menu items when they are objects because I will need to know where the mouse is and the draw method doesn't supply that info.

Next thing to go test after I test the automask.image private class.

But I wouldn't worry too much about it.
I think my custom class will be the better solution for your code.

BITMAP_SourceFile and BITMAP_SelectSourceFile  ?

Mine might be remapping based upon my 64 color workbench.

The first is the normal image and the second is the selected image.  If there is no selected image then the normal one usually defaults.  DrawImageState() can be used to tell the image to draw its selected image (as well as other states) if the image chooses to do so.

Team Chaos Leader wrote:

I will bet your workbench screen is 16 million colors, eh? :) Mine might be remapping based upon my 64 color workbench.

Only 65536.  That might effect getting the desired colours?
If you use your game screen with the colours already 'obtained' with ObtainPen() then I would have thought it would obtain the correct colours.  But I don't know.

I broke one of my files into multiple files and move all of them into a drawer and in the process somehow lost the Storm project.  I should've backed it first.  So I had to recreate this and now it won't access my custom library code.  I don't know why at this stage but rather than keep you waiting I thought I should send the code over to you.  I hope it does what it is supposed to do.

You will need to put the following define in your code that creates the new object:

#define APPAUTOMASKIA_Image 1000000

I simply plucked the number 1000000 out of the air.

To create the class first you will need to call:

  if(pAutoMaskC = AutoMask_Init(void))

You only need to create the class once.
It can be reused to create multiple objects of that class.
To create an object of that class you will need to call:

  if(pCheckMarkI = NewObject(pAutoMaskC,NULL
   ,AUTOMASKIA_Image,&rCheckMarkI
   ,IA_Width,rCheckMarkI.Width,IA_Height,rCheckMarkI.Height
   ,TAG_END))

where rCheckMarkI is your source Image.

You are then free to set pCheckMarkI as your window's checkmark.

When you are finished with the object call:

  DisposeObject(pCheckMarkI);

When you are finished with the class call:

  FreeClass(pAutoMaskC);

Hopefully my example will make classes and objects a little clearer.

I've never used BltClear(...) or BltBitMap(...) before so hopefully they will work as I hope.  I wasn't sure in BltClear() if I should set the last arg as 0x00 or 0x01 (the later meaning to wait for the blitter to finish clearing).

I hope it works as promised.

You need to do the following in the right places:

#define APPAUTOMASKIA_Image 1000000
Class *AutoMask_Init(void);
   if(pAutoMaskC = AutoMask_Init(void))
   if(pCheckMarkI = NewObject(pAutoMaskC,NULL
     ,AUTOMASKIA_Image,&rCheckMarkI
     ,TAG_END))

   DisposeObject(pCheckMarkI);
   FreeClass(pAutoMaskC);

Where there is &rCheckMarkI above substitute this with the pointer to your old Image structure for the checkmark.

I could have written it as a public class but then you would have to install it which you don't want the user to have to do.
So instead I've written it as a private class that you would compile directly into your code.

Datatypes must be "installed", which is one of the reasons I do not like datatypes.

Maybe if I let it cool down for 24 hours it might start working?

Team Chaos Leader wrote:

Can I open it with OpenLibrary()? Libraries do not need to be "installed".

I didn't realise.  I thought libraries had to be installed.
Thanks for that insight.  I'll go turn it into a library.
Hopefully "libs/automask.image" will do the trick.

If you want the full library code I can send that to you as well.
It is in SAS/C format which you seem to use.

You now need to do the following in the right places:

#define APPAUTOMASKIA_Image 1000000
struct ClassLibrary *pAutoMaskCL;
   if(pAutoMaskCL = (struct ClassLibrary *)OpenLibrary(
   "libs/automask.image",0))
   Object *pCheckMarkI;
   if(pCheckMarkI = NewObject(NULL,"automask.image"
     // Replace &rCheckMarkI with a pointer to your Image structure.
     ,AUTOMASKIA_Image,&rCheckMarkI
     ,TAG_END))

and to finish

  DisposeObject(pCheckMarkI);
   CloseLibrary((struct Library *)pAutoMaskCL);

Let me know if you want the full library code as well.

Once this guy FD wrote me an awesome ChunkyFonts.library but he never sent me the source.  A few years later I found some bugs/flaws in his library and I really wanted to fix them.  It would have been ez.  But he lost the source by then.  Now I am stuck with a limited slow library.  grrrr.  So now I always collect source.  We might resurrect it in 2016.

It is in SAS/C format which you seem to use.

SAS/C rulez 4ever! :D
 

You might want to edit the install file in there.
Don't worry, it's only an IconX install script and it only moves the compiled library to where you want it to go.
It also deletes the temporary files that are created during compile.

I currently have it installing automask.library to "//libs".
Change that to instead go to your libs drawer where your game is.

Back to the menu stuff though.  Let's try to work out the range of things that the app writer will want to make available for menu-nisation.  These include:

1. Opening requesters  (eg. Open..., Format Text...)
2. Performing actions  (eg. Cut, Insert Date)
3. Toggling True/False (eg. Grid?, Table Boundaries?)
4. Selecting Options   (eg. RGB?, CMYK?, HSV?, Left?, Centred?)
5. Selecting Sizes     (eg. Font Size 10, Line Width 0.10cm, Grey 20%)
6. Adding Docks & Bars (eg. + Gallery?, + Rulers?, + Draw Bar?)
7. Addhoc Items        (eg. "RAM:MyLastDoc", "Untitled 1")

Any more suggestions feel free to add.

One is that you may want to group somethings.
For example you may offer left|centre|right alignment and you may offer top|centre|bottom alignment.  You might want to combine a couple of these into one step eg. top+left alignment.
Another example may be combining bold+italic in one action if you do it a lot.  Or even setting a set font size, style & format in one action.

The other trick is that you want the menu to maintain consistency.
So for example if the user selects bold off while bold+italic is on then this should also go off.  If there is an italic option this should remain as on or true.

The best way to implement the later I think - instead of using a mutual exclude field of limited size - is to actually associate a class object with each function/option/etc.

In this way it should be possible to design methods that will allow whether menu items should be shown as chosen or not.  When the menu is edited and saved then the associations can be worked out by querying the objects and creating chains of exclusions.

It also simplifies the process of supplying functions/options/... to the menu system as you need only create a new object for each function/option/...  Setting the attributes via the usual way it can then be supplied to the menu system.

The other thing this allows is a means for the application to update the options as things change and for the objects to be chained for those which have been selected and the application notified to traverse this selection chain.

The first usually has a fixed form and is usually the easiest to specify.  However the option to have alternate versions based upon situation - such as Undo Resize - will mean that in those instances the class object will need a list of forms that it can be told to be by the app and in the menu editor each of those forms would be able to be given a label per language.

The second can be represented in the menu by checkmarked items (eg. [] bold) or by an 'on' option &/or and 'off' option (bold on, bold off).  Selecting the on/off options would have to alter any [] forms and when the on/off option can't be done - because it already is - it would be ghosted.

The third form can be represented by a radio item, or even as part of a cycle item, to indicate that there are other alternate possible values.  The menu preference user would make a selection of preferred values that they would like for these.

Where the second one becomes part of a combination of options then it would instead become like a radio item.  So for instance a 'bold+italic' no longer just has two forms.  It also has 'bold+!italic', '!bold+italic' and '!bold+!italic'.

There is also another form that you see sometimes these days where you can increase or decrease a value instead of picking a value.  For example, Increase Volume.  So this also needs to be an option for range values.

The best way to implement the selection of values is to have the class object, that is provided by the tool to add a function, also provide the means for picking the value.  Like a little plug-in.

This will then appear as part of the menu editor in a set aside spot when the user is editing a menu item.