• Austin's new Gumps

Posted: **Thu Jan 04, 2007 3:23 pm**

I've been around long enough to see 3 different ways of doing gumps. And old enough to admit I am mostly out of my depth with gumps in general. Doing gumps is the slowest part of my coding and the most dreaded.

First there was the data and layout arrays and lots of ingenious ways to plug values into the arrays and a real headscratcher to follow. My shard is based on the WoD scripts and that's how Dundee and Drocket coded.

Then we had the first version of GFGumps where you could basically assign any legit variable xxx (number, array, dictionary etc) to a button eg xxx := Button.... - a dictionary was darned handy when using attributes instead of skillids. All in all it was very easy to code in because you had full control over the array you were building up on the left side of the expression and that made it really easy to analyse the gump return.

Now we have the third version which has some plusses and minuses for me. It's not hard to code in, but I really do have problems with the GFAddButton command because it goes back to the first method of creating gumps and wants an integer as the return value of the button press. (gumps.inc does a CInt() on the value you assign)
eg GFButtonAdd(gump, x, y, pic1, pic2, closeoption, returnvalueifpressed);

I admit I'm a newbie on the newest gump system and only really worked on one script. It's really easy to convert ancient gump code to this new system, but not so easy to convert from the first version of GFGumps to this new version.

Why? Because I am removing all instances of SKILLID from my code. That means the second gump system is the easiest for me. The third way works too, but I have to convert from the ATTRIBUTE_ID to a unique gumpbutton integer without using skillids. Is using an array with all the skill attributes in it and simply using the index the best way to do it?

I need to understand all this now before I go and take too big a bite. I am committed to re-writing my gumps to have consistent code that's more modern, but right now I would be grateful of any advice by those who have adopted the new gump system.

Posted: **Mon Jan 08, 2007 3:27 pm**

Perhaps the answer to my question is to use:
_(var)_iter to set the return index in GFAddButton

As posted above - obviously puzzling to all readers - my issue with the new gumps system is how I set sensible values to GFAddButton since it now expects an integer as the last parameter and I don't want to convert to skillids.

Since a lot of my gumps are players selecting attributes, I was resorting to converting the attribute to a skillid as the GFAddButton value. Now with the wonders of _(var)_iter maybe I can rethink. Simply use an array of all attributes and use foreach in the loop.

I don't blame you for not responding to my gump query. I am either the only one who finds gumps a pain, everyone is as confused as I am, or everyone can't be bothered working out what the heck I am on about.

Posted: **Mon Jan 08, 2007 11:54 pm**

I'm with you on the issue of gumps OldnGrey.

They are the slowest part of my coding too. Not that there's a fast side to any of my coding.

Posted: **Tue Jan 09, 2007 12:09 am**

You have always had to set an integer value for gump return values in buttons, check boxes, radios, etc. If you don't pass an integer value for it, it assigns one, the return value (as noted in teh comments above the functions and in the gumps docs) will be the button's return value.

It works that way regardless of which gumps system you use.

Attribute names can be an array of strings.
The gump is a list with button values.
The button value could point to an index in that array.

Code: Select all

foreach attrib_name in (attribute_list)
   GFAddButton(gump, x, y, on, off, GF_CLOSE_BTN, _attrib_name_iter);
endforeach
....
var input := GFSendGump(user, gump);
var value_clicked := input[0];
var attribute_selected := attribute_list[value_clicked];

Code: Select all

var btn_id := GFAddButton(gump, x, y, on, off, GF_CLOSE_BTN);

Side Note:

If you needed return values in that range.. you could just like.. add 5000 to every _attrib_name_iter value, then check if the input is over 5000, so you know for sure an attribute was clicked, then subtract 5000 to access the array properly.

Posted: **Tue Jan 09, 2007 2:39 am**

Austin,
Your second example is very like the old GFGumps - is it still legal to set the value with a := like that? Thought it all had to be as the last parameter in the braces? I haven't seen any examples of that used in the distro that I could see.

yours:
var btn_id := GFAddButton(gump, x, y, on, off, GF_CLOSE_BTN);

expected:
GFAddButton(gump, x, y, on, off, GF_CLOSE_BTN, btn_id);

old gumps:
var whatever := GFButtonID(x, y, release, press, close)

Posted: **Tue Jan 09, 2007 2:56 am**

well... ill post the function's header

Code: Select all

/*
 * GFAddButton(byref gump, x, y, off_id, on_id, btn_type, btn_value)
 *
 * Purpose
 * Adds a button (page/reply) to the gump
 *
 * Parameters
 * gump:	Reference to the gump
 * x:		The top-left spot of the X axis.
 * y:		The top-left spot of the Y axis.
 * off_id:	The release-id (graphic) of the button.
 * on_id:	The pressed-id (graphic) of the button.
 * btn_type	The type of button to use:
 *		GF_PAGE_BTN	Will move the gump to another page.
 *		GF_CLOSE_BTN	Will close the gump and return the value of the button and other data.
 *		GF_DUMMY_BTN	Seems to do nothing but change the graphic when you click.
 * btn_value	If the button type if set to a page, it will go to the assigned page number.
 *		Otherwise, if clicked, it will return the value. If set to 0, it will assign the
 *		next available usable number.
 *
 * Return value
 * Return value is the button value.
 *
 */
function GFAddButton(byref gump, x, y, off_id, on_id, btn_type:=GF_PAGE_BTN, btn_value:=0)

Posted: **Tue Jan 09, 2007 3:05 am**

Well, I'll be a.......