Sounds great... So now it looks like I don't have any more excuses not to develop anymore !

Jerry

_________________
- AOS has been ported to ex-86 ! It's called AROS and WinUAE... Or E-UAE on Linux !

- A1XE-G4 up and runing with:
512MB Ram / 200GB and 80GB HardDisks on Sii0680.
AOS4 Final Update / AmiZilla 0.1 Alpha

Really nice

I would also hope that I could afford the FDSP, but I am not able to

_________________
Best regards,
hnl_dk - Henning Nielsen Lund [Denmark]

Please send no PM to me, email me if you want to contact me. See you somewhere else.

cool

_________________
See my blog and collection website! . https://www.blog.amigaguru.com

This Template project is a very useful thing, IMHO.
I could take a look at how the Menus and Event handling are now with Raction in OS4.0
(many things have changed and are much easyer now as with OS3.9).

_________________

Sounds great !

Effectively now the developpers have no exuses for going on with applications developement

Unfortunately i'm not programmer but probably it is a very very useful tool ! So GO ON !

And nice job from the AVD Team !! Hip hip hip Hurray !

_________________
RedOneX (SAM 460ex) and an A1 which now rests quite.
Amiga OS 4.1.6 and CinemaWare games.
Classic and NG softwares.

Jamie Rules !

_________________
Moxee
AmigaOne X1000
AmigaOne XE G4
I'd agree with you, but then we'd both be wrong.

Anyway: there seems to be a little error in the comment of creategui.c in the line:
Quote:

WINDOW_NewMenu, (struct NewMenu *)&pOSApp->oWindowMenu[0], /* Since we are using the Menu's nm_UserData field to store custom Menu IDs, we need to tell the Window class to ignore them */ WINDOW_MenuUserData, WGUD_IGNORE,

The comment suggest we would use custom Menu IDs, which is at least not the case here, but the Menu IDs are just the ancient static IDs for old style Menus. Am I missing something ?
(I really would like to use custom Menu IDs, can someone tell me how I get the UserData field.)

Last edited by _PAB_ on 24-Nov-2005 at 10:43 AM.

_________________

It uses the menu items' userdata fields to store the ids, this means that it doesn't need to rely on the oldstyle ids for anything else than finding the relevant menu item struct from the menu strip. At least this is the method I used in my xml menus program:
http://a500.org/index.php?s=downloads&f=eguidemo.lha
Judging by the comment you just quoted, AVD uses the same method.

Last edited by salass00 on 24-Nov-2005 at 02:58 PM.

Quote:

Anyway: there seems to be a little error in the comment of creategui.c in the line: Quote: WINDOW_NewMenu, (struct NewMenu *)&pOSApp->oWindowMenu[0], /* Since we are using the Menu's nm_UserData field to store custom Menu IDs, we need to tell the Window class to ignore them */ WINDOW_MenuUserData, WGUD_IGNORE, The comment suggest we would use custom Menu IDs, which is at least not the case here, but the Menu IDs are just the ancient static IDs for old style Menus. Am I missing something ? (I really would like to use custom Menu IDs, can someone tell me how I get the UserData field.)

What you are seeing in this case is the result of setting the code up
for handling Menus dynamically, including having the menus restored
cleanly between Iconify/Uniconify and hide interface/show interface
actions, only to have all my new style tests crash and burn. Since the
menus were simple and I did not want to hold up the release of this
update because of it, I set the ID system back and used the WINDOW_NewMenu
attribute.

This menu code will be revisited when I get a chance to add visual
menu creation in AVD's GUI Builder component. In the mean time,
sorry for the confusion.

Here are some references to what we are talking about :

From the "window_cl.doc" AutoDoc file:
WINDOW_MenuUserData (UWORD)
Like the WINDOW_GadgetUserData tag, but for menus. Using
this implies that WINDOW_MenuStrip has been created with
GadTools or otherwise has a 32-bit UserData field after
each menu item.

From: os_InitOSApp() - AVD Template sources

/* Menu -Item("Quit","q",MENUID_QUIT) */
pOSApp->oWindowMenu[6].nm_Type = NM_ITEM; /* (UBYTE) Menu Type (ie. NM_TITLE) */
pOSApp->oWindowMenu[6].nm_Label = "Quit"; /* (STRPTR)Menu's label */
pOSApp->oWindowMenu[6].nm_CommKey = "q"; /* (STRPTR)MenuItem's Command Key */
pOSApp->oWindowMenu[6].nm_Flags = 0; /* (UWORD) Menu or MenuItem flags */
pOSApp->oWindowMenu[6].nm_MutualExclude = 0; /* (LONG) MenuItem MutualExclude word */
pOSApp->oWindowMenu[6].nm_UserData = (APTR)MENUID_QUIT;
/* (APTR) For your own use (ID, Pointer to Hook Function, etc.) */

Also, check out the RKRM Libraries, p372, and point your SDK Browser at
Libraries->gadtools->libraries/gadtools.h for the definition of struct NewMenu
and the GTMENU_USERDATA() and GTMENUITEM_USERDATA() Macros.

Best Regards,

Jamie

Last edited by JamieKrueger on 25-Nov-2005 at 01:53 AM.

_________________
Jamie Krueger
BITbyBIT Software Group LLC
jamie@bitbybitsoftwaregroup.com
PLEASE NOTE: I only speak for myself and my company,
and am not a spokesperson for Amiga Inc.

@Jamie:
Quote:

Since the menus were simple and I did not want to hold up the release of this update because of it, I set the ID system back

No problem, I was just wondering how the new style works and looked only in the Raction examples... will take a look at the proposed autodocs.

_________________

Just a little remark:
in os_processevents.c.html this comment:
Quote:

} /* If sigwinmask */

should be three lines below, I guess.

_________________

Quote:

Just a little remark: in os_processevents.c.html this comment: Quote: } /* If sigwinmask */ should be three lines below, I guess.

Yep, side effect of the last update. Thanks.

I sure a great deal of the comments and
headers need some work.

Rest assured this is not the last version. :)

Best Regards,

Jamie

_________________
Jamie Krueger
BITbyBIT Software Group LLC
jamie@bitbybitsoftwaregroup.com
PLEASE NOTE: I only speak for myself and my company,
and am not a spokesperson for Amiga Inc.

I've read the website, seen the screenshots. It looks great. Before deciding, it would be interesting to hear from some who are actually paying subsrcribers. Apart from the obvious benefit of supporting Amiga companies, is this worth to subscribe to?

I'm already positive to this, But $120 is a relatively non-trivial investment for me and I would also love to hear some comments from real users, and hear your impressions too.

Thanks,
SlimJim

slimjim: i'd say go for it, i did and i aint regretting it.

_________________
See my blog and collection website! . https://www.blog.amigaguru.com