Not sure if its possible or if there's an alternative to it but, is there a way possible to grab a button's text / ID? (preferably without the use of winget() as it usually moves a lot slower than other stuff)
The scenario is being able to pull the "text" (or ID doesn't really matter which) of a button on the interface by clicking the button, and its then saved to a variable. The variable is then done in a switch-statement for the different possible strings the "text" could be and then a different code responds to each possible string. (A lot easier than making a different piece of code for every button when the code differs only by so little)
Thanks in advance.
ID:155444
 Jul 6 2011, 3:04 am
|
|
|
Jul 6 2011, 4:05 pm
|
|
GhostAnime
 |
You can always pass the text off as an argument of a verb when clicking the verb. My DM is rusty but something akin to this may work in the button's call verb section
|
While this is pretty much what I want, there's but two issues I see with this:
1) -- This uses the winget() to get the text of the button and that usually runs slower than any other function. So I want to avoid using it as much as I can. 2) -- To use the winget(), you need to put in the control you want the "text" from. As I'm using about 20 different buttons per pane, this would be still kind of lengthy in the actual code. So unless it's possible to just leave the control value blank in a if-statement, I don't think it'll work as well as I want. Example: if(winget(src,null,"text") == "Test Button") src << output("It works!","Chat") (If this is the format I'd have to use, I'd have to do that if-statement for about 20 different buttons) This is all assuming that, "the property to get the text, you can find it through the Help > Skin Reference" is referring to using the winget(). If it ain't well, I'm not sure what you're speaking about. | |
Did you even read his post? No where in it does it use the winget() proc. Ghost is talking about using a verb assigned as the button's command that passes the ID or whatever text as the verb's argument.
//verb in the code As you can see. No winget calls. | |
Erhm, I think its you who mis-read his post or something. He even comments about, "Skin Interface" Also, he has "this." meaning the "this" pointer which refers to whatever it would be clicked (Hence, the button). What you just gave is something very similar to a say-verb. Like, my own speech-verb is literally the same thing to what you just gave me. So I think you should re-read the stuff again.
P.S. I also said, at the ending of my statement, "This is assuming that the way to get the text is using the winget(). If not, I don't understand". | |
Your speech verb is the same thing? I didn't know your buttons could be psychic like that... I assure you that winget() is not required and neither was it ever mentioned in Ghost's or my own posts. It is just you who fails to comprehend what Ghost and I are referring to.
EDIT You make an assumption. I tell you you are wrong, and show you exactly what Ghost is talking about for you to play around with, and yet you still make the same assumption without even TRYING it first? | |
Your code was:
client/verb/Verby(t as text) src << t Was it not? That line right there is pretty much the same as: mob/verb/Verby(msg as text) src << msg Which is my basic say-verb at the moment as I haven't begun implementing spam-blocking and stuff in it yet. Tell me you at least see that it's LITERALLY a say-verb just set for individual machines instead of individual mobs.Your only exception is the line: Verby "text" Which doesn't tell me jack-squat. Now with all that said, that should make it clear why I didn't even BOTHER trying to, "play around with it", when what've you just told me makes as much sense as what I just explained. Not to mention, Ghost's post was pretty different from yours in the sense that his had comments stating the "Skin Reference" which OBVIOUSLY would bring question to the winget(). Furthermore, the "this" pointer is used to reference the procedure/function/object the process is running through, i.e., the button, which is even MORE REASON I wouldn't have tried yours because you have nothing similar to that in my opinion. So -- I believe my assumptions were well placed seeing that you didn't properly explain this stuff to me (Even though I had my little 'pardon-me-if-I-didn't-understand' clause at the bottom of my reply to him) I'm first trying to understand it, before just putting it in and not understanding a thing. NB: Now, beside all that pointless bickering, pointing of fingers and digression of, "what I assumed" from "why/what I didn't try", do you care to explain it now or not? | |
She gave you exactly what you needed to solve your problem. What she did not do was give you the code outright, denying you a chance to learn something new. So, allow me to explain in detail what goes on in the setup she posted.
client/verb/Verby(t as text) src << t A verb, which, when used, will output the first parameter(t) as a text string to src. Verby "text" This is the command you would use in the command line/a button to call this verb with the aforementioned parameter (t) being "text". Calling the verb in this manner will display "text" to src. How this is useful for your purposes is simple. You use t in a switch statement and change "text" to whatever you want in the button's command. If you want t to be "hello" you would put: Verby "hello" And use: switch(t) if("hello") world<<t if("text") src<<t This, when combined with one button calling Verby with the parameter being "hello" and one being "text" would provide 2 responses when the buttons are clicked. Being rude/belligerent because you don't understand something won't get you much help, but to clarify something quickly, I'll say this. When you come to the developer forums asking for help, don't expect people to hand you a working copy of what you want, as, again, that would deprive you a chance to learn something useful. In your defense, that was a fairly vague post on spunky_girl's part, and it could have been explained a little bit better to allow for a less knowledgeable programmer to understand everything that's going on. Sometimes programmers tend to not notice that some things, while obvious to them, won't be so obvious to the people they're trying to help. Try to be aware of this, and if you don't understand, ask for clarification on the parts you don't get, rather than simply saying "This isn't what I want, it won't work." | |
Thanks alot Rob, I think i actually get it now.
For the record, I wasn't expecting anything "hand-fed" to me where I could just, "throw it in" and it works (since I've been posting stuff on the forums now for a while and pretty much know how it works), I wanted to actually understand what it was I was looking at before throwing it in and fidgeting with it. Literally, it makes no sense buying a car if you don't know how to drive it and I'm certainly not gonna' get behind the wheel anyway and kill myself in a car-accident (if you get that analogy). While I admit, maybe I should've asked what it was she was explaining, it just looked awe-strikingly similar to a basic say-verb, so I was pretty sure she had mis-read something, and for that I apologize. But I digress, I've got an idea now thanks to you all, thanks alot. | |
While learning to program and/or use a program, it is extremely important to test things out yourself, which may involve jumping in the driver's seat without knowing how to drive sometimes.
Also, making assumptions just makes you look like an... well you get the idea. | |
Experimentation is quite important, but you can't try things for yourself if you don't understand the basic concepts behind what's going on. Giving a vague example with no real direction or explanation of what is going on isn't much better than simply giving them a finished solution.
In this particular case, Sieg didn't fully understand the concept of parameters that can be passed between procs/sent through buttons. Without explaining this function, he likely wouldn't have figured anything of value out by just toying with what he was given, and even if he DID manage to make it work, he wouldn't have understood why it worked or the underlying concepts that are important in other areas of programming, causing him to miss out on a perfect chance to learn more about the language as a whole. In my opinion, teaching is a balance between allowing the person to experiment for themselves, while still giving them all of the information they need to learn in an environment that is more supportive of their needs. This balance is unique for everyone, and changes at various stages throughout the learning process. Some people need more guidance than others, while some can do just fine without much assistance. Regardless, this is getting quite far off topic. | |
Just to clarify, what Spunky_Girl had mentioned earlier was what I was trying to convey. I have been using JavaScript and Action Script (Flash) lately hence the "this." portion and the incorrect format for passing an argument to the verb from the button. Sorry for the inconvenience and I apologize for the befuddling post.
| |