text scroll list

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  01 January 2004
text scroll list

Does anyone know if it's possible to have a different command be executed depending on which item in a text scroll list is double clicked. In the docs, it looks like it just works generally. No matter what is double clicked on produces the same result. If it's not possible, does anyone have an idea how to have a list of object with different command shooked up to each one?

Thanks for any help.
 
  01 January 2004
your are right, the textScrollList executes the same command for every doulbe click.

One way around this is to have a proc that can determine whats been click and then makes the appropriate call to another proc.

--g
 
  01 January 2004
Thanks for the reply. I don't know if the proc thing will work for me, I'll have to mess around with it. Basically what I want to do, is when you click on a button, it adds a line of text to the text field. Then when you click on the item in the text field it lets you edit properties of that button. This means that whatver is run when the item is clicked has to know the specific name of the button pressed. The only wasy I can think of at the moment, is to have th eline of text be the actual command, and then just feed that string to the "eval" command. Unfortunately this is very intuitive in my script.

If anyone has any ideas, they would be greatly appreciated.
 
  01 January 2004
its pretty easy to do what you're after using GDC suggestion.

so just say u have a scroll list with 3 things in it:
itemA
nextItem
nipples!

then you have two buttons:

button -l "select item" -c( "doAction select" );
button -l "delete item" -c( "doAction delete" );

then have the doAction proc look something like this:

global proc doAction( string $action ) {
string $selectedItem[] = `textScrollList -q -selectedItem nameOfUI`;
switch($action){
case "select":
select $selectedItem;
break;

case "delete":
delete $selectedItem;
break;
}
}

that'll allow u to do pretty much whatever u want...

PS most of that code is probably wrong, so don't go cutting and pasting. I didn't refer to the docs, so the flag names are probably wrong.
__________________
-:macaroniKazoo:-
 
  01 January 2004
makaroni: Thanks for the help.

That would work if the action I wanted to perform used the exact name in the textscrolllist, but if it doesn't, then the procedure thing doesn't seem to work.

Let's say the list contains:
myButton
mySymbol
Button2

If I doubleclick on one of them, I want an edit window for that item to open. For this to happen I call my edit procedure with the name of the button as an argument. Since the name of the buttons that can't be passed to the procedure aren't known before it is run, I pass the entire name of the button, such as window2|columnLayout1|myButton. I have to do this, since there could be multiple buttons with the same names. So basically, I need the list to run something without relying on the actual strings in the list.

I might just have to find out another way to do it.
 
  01 January 2004
i just sort replied to this thread on melscripting.com...

but yeah, try using something like a rowColumnLayout with a checkbox, and text. checking the checkbox "selects" the item.

the advantage of this, is that you can store individual info with each item in the UI's docTag.

for example, create a proc that makes a new rowColumn layout. 2 columns wide, the first column has a checkbox, the second, plain text. right clickin on the text could bring up a menu of commands to do to that particular item. the full path name of the thing can then be stored in the docTag of either the text, or the rowColumnLayout... you could also make left clicking the text select the item as well (ie have a popupMenu work on left click, which simply checks the checkbox relevant to that item)

this way certainly gives u heaps more power in terms of what you can do with each individual item. i have a lot of scripts use similar technique.
__________________
-:macaroniKazoo:-
 
  01 January 2004
another pointer:
most UI-elements store annotations with the -ann flag. if you put complicated bullshit into that , like e.g. path-names, you can still query that and still give your buttons nice names.

another thought: your proc can parse your buttonNames for keywords like "nippleButton", "nippleSymbol" or "nipplePinch" , and then "switch" for occurances of your keyword like:

switch ($myString)
{
case Button:
doSomething ;
break ;
case Symbol:
doSomethingElse ;
break ;
case Pinch;
doTHATagainAndIwhackU ;
break;
}
etc...

third:
your buttons can have the same dynamically created name but with increments in number.
to make this more clear, let's say you have a procedure that creates a new element in your list by something like:

int $c , $ni ;
// in case the window exists but is first used
if (`window -ex "myWin"`){
$ni = `textScrollList -q -allItems nameOfUI`
if ($ni == 0) $c = 0 ;
// if it exists and has buttons
else if ( $ni > 0) $c = $ni ;
}
// if the window does not exist yet then $c (for count) is "0" anyway
else if (!`window -ex "myWin"`) $c = 0 ;

string $button = `button -l "nipplePierce1" ("myButton_"+$c)` ;

that way your very fist button will be referenceable as "myButton_0"
and any subsequent will be "myButton_1", "myButton_2", etc...

try it.
HIH
s.
 
  01 January 2004
Quote: most UI-elements store annotations with the -ann flag. if you put complicated bullshit into that , like e.g. path-names, you can still query that and still give your buttons nice names.
yeah brubin, its better to use the docTag for that, because the annotation flag is visible to the user. if you hover your pointer over a ui object for long enough, it displays the text stored in the annotation flag. so better to store it where the user can't see it.

well, thats my opinion anyways.
__________________
-:macaroniKazoo:-
 
  01 January 2006
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 05:35 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.