Problem with new scripting method (UTTERLY SOLVED)

[Rui 'Trovatore' Pires]

So, I used to have this "char invlist", which only ever had the values "1" or "2". I used it to flexibly use, listbox 1 or listbox 2 in a certain GUI.

Naturally, with the new object based scripting, this had to go. And I deleted the char and started using Listbox *invlist to set the value I wanted.

HOWEVER, since global pointers aren't allowed, I had to keep the previous char, renaming it to "invlistchar" in order to check the value at the beginning of each called function. This is a lot of fuss, and this sort of thing makes the new method a bit more uncomfortable than the earlier, as this sort of thing used to be painless, and although that's NOT the point of this post, I have to say that at times like these I miss the old system. I had to replace a "GUIOff(guinumber);" by 18 lines, each turning off the GUI in question if the variable "guinumber" was that GUIs! But, back on topic.

In one particular function, I called a listbox GetItemText, for listbox "invlist". This was the first place where I had to use the char to find out which was the value of invlist, and therefore, which listbox I should deal with.

Here's the problem. When I do THIS

Code: ags

if (invlistchar==1) {
Ã,  Ã,  ListBox *invlist=lstInvI;
Ã,  Ã,  ListBox *invlistsee=lstInvSeeI;
Ã,  }
Ã,  else {
Ã,  Ã,  ListBox *invlist=lstInvII;
Ã,  Ã,  ListBox *invlistsee=lstInvSeeII;
Ã,  }
Ã,  invlist.GetItemText(invlist.SelectedIndex, buffy);
Ã,  etc, etc, etc

I get the following error:

---------------------------
Compile Error
---------------------------
There was an error compiling your script. The problem was in 'Global script':

Error (line 239): Undefined token 'invlist'

line 239 is invlist.GetItemText(invlist.SelectedIndex, buffy);

Ok, I thought, I can dig it. What will I do now, I wondered? I can't declare it AFTER the "if" check, or it'll override the contents... so I'll declare it BEFORE! And it ends up like this.

Code: ags

ListBox *invlist=lstInvI;
if (invlistchar==1) {
Ã,  Ã,  ListBox *invlist=lstInvI;
Ã,  Ã,  ListBox *invlistsee=lstInvSeeI;
Ã,  }
Ã,  else {
Ã,  Ã,  ListBox *invlist=lstInvII;
Ã,  Ã,  ListBox *invlistsee=lstInvSeeII;
Ã,  }
Ã,  invlist.GetItemText(invlist.SelectedIndex, buffy);
Ã,  etc, etc, etc

Yeah, right. I got the following message:

---------------------------
Compile Error
---------------------------
There was an error compiling your script. The problem was in 'Global script':

Error (line 233): Variable 'invlist' is already defined

...line 233 being, naturally, ListBox *invlist=lstInvI;.

What gives?

[strazer]

I had to replace a "GUIOff(guinumber);" by 18 lines, each turning off the GUI in question if the variable "guinumber" was that GUIs!

Beta 9 has a gui[] array, so you can do
  gui[guinumber].Visible = false;

[Pumaman]

This is a lot of fuss, and this sort of thing makes the new method a bit more uncomfortable than the earlier, as this sort of thing used to be painless, and although that's NOT the point of this post, I have to say that at times like these I miss the old system.

It's interesting feedback, nonetheless. If there's a way to make it better, then we should try to find it.

How about some sort of GetControl(int number) function on the GUI, which returned you the control pointer?

I had to replace a "GUIOff(guinumber);" by 18 lines, each turning off the GUI in question if the variable "guinumber" was that GUIs! But, back on topic.

As strazer says, you could just do:
gui[guinumber].Visible = false;

if (invlistchar==1) {
    ListBox *invlist=lstInvI;
    ListBox *invlistsee=lstInvSeeI;
  }
  else {
    ListBox *invlist=lstInvII;
    ListBox *invlistsee=lstInvSeeII;
  }
  invlist.GetItemText(invlist.SelectedIndex, buffy);

The problem is the scope of the variable. When you declare a variable, it goes out of scope at the } corresponding to where it was declared. So, do this:

  ListBox *invlist;
  ListBox *invlistsee;
  if (invlistchar==1) {
    invlist=lstInvI;
    invlistsee=lstInvSeeI;
  }
  else {
    invlist=lstInvII;
    invlistsee=lstInvSeeII;
  }
  invlist.GetItemText(invlist.SelectedIndex, buffy);

[Rui 'Trovatore' Pires]

Strazer - thanks a lot! I didn't know that was in there.

CJ - 1) Hmmm.... that might work, but how about arrays such as the one Strazer pointed out? For listboxes, buttons, CHARACTERS too - I recently had a slight problem with those, althuogh it's fixed now. WOuld that be feasible?

2) Yeah. Thanks again, Strazer! And thank YOU CJ. That's a mighty handy feature.

3) *groan* I can't BELIEVE I forgot to also declare invlistsee! DumbdumbDUMB!

Thanks again to both of you.

[Pumaman]

Hmmm.... that might work, but how about arrays such as the one Strazer pointed out? For listboxes, buttons, CHARACTERS too

I don't know what you mean by "CHARACTERS too", there is already a  character[] array.

[Rui 'Trovatore' Pires]

Christ, I'm really outdated.

But I presume you didn't saying "no" means that you're considering it... right?

[Pumaman]

In terms of listbox[], button[], etc, I'm still considering the best approach to use.

[Rui 'Trovatore' Pires]

Code: ags

if (keycode==372) {
        if (ListBoxGetSelected(guinumber,0)==0) ListBoxSetSelected(guinumber,0, ListBoxGetNumItems(guinumber,0)-1);
          else ListBoxSetSelected(guinumber,0, ListBoxGetSelected(guinumber,0)-1);
        }

Gah, this objectivation is really getting on my nerves... this is user feedback, BTW - this is why I ALWAYS use betas, so I can give good true feedback.

The above code is for the UP arrow key - if the player presses it, while in a menu, naturally, (a check that isn't seen in the excerpt) the selection either moves upwards or wraps.

Well, I could have gotten away with it the way it was... but what about now? What can I do? And whatever I do, it's apt to get messy.

Maybe SOME things shouldn't be objectised, for these reasons... things that were so neat before are turning into a headache.

[strazer]

Yeah, looks like that GUI.GetControl(int number) would come in handy.

[Rui 'Trovatore' Pires]

Heh. Linking to the same message?

But yeah, I agree, maybe it'd solve things much more efficiently than that listbox[] thing.

[Pumaman]

I'm just wondering whether global pointers would actually be a cleaner solution here -- so you could save a ListBox* pointer rather than "guinumber". Would that be more useful?

[Rui 'Trovatore' Pires]

It's starting to be too much for me, I can't say go too far without actual experimentation... how would that help the second thing I posted? I'm better at practical coding, and now we're on abstract ground...

[Pumaman]

Well it's hard to tell from a code extract without any context, but I presume you're setting a guinumber variable somewhere; wherever you set that, you could in theory set the global lisbox object instead, and then use that.

Anyway, I think what I'll do is add functions like:
gui[].GetListBox(int index)
gui[].GetButton(int index)
etc

hopefully that should satisfy everyone

[Rui 'Trovatore' Pires]

Hmmm, yes, that sounds swell. And yes, "guinumber" is a variable depending on which GUI is on, and therefore which listbox should be processed.

So what I'd do would be something like

Listbox *list=gui[guinumber].GetListBox(0);

And then use the newly created "list" listbox, yes? Gotcha.

One more thing, though - please don't discount the possibility of global pointers. : Really, I often find myself declaring the same things many times, on account of all the functions I have...

[Rui 'Trovatore' Pires]

Sweetness!

ListBox *lstingui=gui[guinumber].Controls[0].AsListBox;

and my problems are solved! Thank you very much, CJ! WHOOO-HOO!