T3h B4tman wrote:
winget(client, id, "parent")
winget(client, id, "children")
There is a workaround, as stated by Falacy in the quoted thread, but it'd be nice to have it as a simple winget() call.
ID:109458
 Feb 12 2011, 2:00 pm (Edited by moderator on Nov 29 2011, 1:34 pm)
|
|||||||
| |||||||
Copied from id:724148.
T3h B4tman wrote: There is a workaround, as stated by Falacy in the quoted thread, but it'd be nice to have it as a simple winget() call. | |||||||
I guess an explanation of my dire need for this would help.
My mouse tracker works by auto-generating a browser window of the same size, position, and parent. This way, I can simply send to use a loop in JavaScript to track, calculate, and pass on mouse coordinates to the server. Anytime the map were to resize, the browser would to, having the same anchors. The only variable that has to be manually tracked is map.icon-size. Anyway, the current method of finding the parent is: winset(src, "map", "focus=true") This leads to problems as the focus can change between calls because of unpredictable factors on the client's end. I have an update that I'm working on to hammer out new features and iron out old ones but I need this feature in order for the library to even function properly on a constant basis. | |
I would like to add that Audeuro's Bug Report on using winget() for control IDs was posted within a week of this request and addressed a few weeks later with the message, "Trying to use winget() to get the read-only "id" parameter did not work. This now returns the control's name. It does not return the full window.control version of the name." Why wasn't this addressed then?
| |
Yeah. If there's a workaround, this feature should be pushed back in favor of features that don't have workarounds.
| |
I'd rather see mouse tracking as a built-in feature to just make this obsolete.
| |
Maybe then, you should read the comments again. The workaround isn't a hundred percent accurate. And mouse tracking isn't the only reason that this should be added. Completeness, for one. Common sense for another.
P.S. Falacy, you're an idiot. Reasons: No votes? No shit. I was trying to draw attention to it because of the lack of attention and support. The workaround doesn't always work properly, especially when the client first connects. Interfaces are bad? You're an idiot. Deleted topic, probably not. Deleted or edited posts, probably. Banned from the tracker, most likely. Actually, to be honest, I was going to call you an idiot again for the "1 day a month" comment but it seems that while you may be exaggerating (a bit), you're on to something. I have been cursing here for two reasons, A) This topic has no attention, and B) I wanted to see if the staff actually paid any actual attention to the tracker. Apparently not. | |
Hiro the Dragon King wrote:
No sir, you're an idiot for suggesting that not using an interface is better than using an interface. Let's go back to 3.5 and just use info panes again. That's so much better looking. I'm sure all of the professional programmers will want to use our suite then.Interfaces or not, majority of BYOND games still use stat panels. The proper solution is to use in-game HUDs. Some developers make the attempt of having interface controls appear as actual HUDs, which is at least a false step forward, but majority of them just use interfaces as the blatantly pathetic looking windows API controls that they are. Feel free to find a single commercial game that uses windows controls as its UI, and then you can make an argument about "professional programmers" being interested in BYOND because of it. Instead of wasting any more time on interfaces, BYOND should spend time on creating efficient, built-in, easy-to-use, customizable systems to handle HUDs. In just a few lines of code with Unity, you can create dynamic text, backgrounds, images, inputs, sliders/bars, buttons, etc. It all updates every frame (which can be thousands of times per second) while using next to no resources. Good luck creating even a simple system with BYOND that can write on-screen text every tick without it being the most CPU expensive thing in your game. If BYOND were to create built-in HUD systems, they could be handled almost entirely by the client (as interfaces are now), making CPU usage nearly irrelevant. | |
I'm not sure what the problem is exactly. If you placed the controls in the interface editor, there might not be a way to use code to get the parent/child at runtime, but wouldn't you, as the developer who made the interface, know what the parent/child relationships are? You could store those relationships in variables.
| |
Falacy, I actually... agree with you. HUDs are everything an interface should be. For example, Ultimate Jigsaw's interface was created entirely by HUDs. In fact, practically the entire game is handled via the HUD. Though, there were a few issues that needed to be worked out and I did, though I never released the fixed update. Even so, a lot of work had to go into the interface to get it to work the way it does, including the workaround to the above feature and editing the interface in Notepad++.
Work on that game, along with something that I believe D4RK3 54BR3 was working on, alerted me to the issue with the workaround. That issue is that the workaround is spotty, especially when the client first connects and on bad connections. Being able to winget() parent IDs would completely negate this issue. And Forum_account, no, as a developer of a library, I would not know what a developer using the library would be placing in the interface editor, spotty workaround aside. | |
Hiro the Dragon King wrote:
And Forum_account, no, as a developer of a library, I would not know what a developer using the library would be placing in the interface editor, spotty workaround aside. Make the library require that the developer using it specifies the control's parent or child (whichever you need). Instead of calling some_proc("control") you'd call some_proc("parent", "control"), or some_proc("parent.control"). | |
Seeing as the developer can use multiple controls and that the controls are stored in a list, I would either have to create a second list for parent IDs (and people seem to have enough trouble with the controls list) or have developers use full control names in the list and parse the names. The first solution is unintuitive and would lead, most likely, to more user frustration. The second is ugly, even more unintuitive, and prone to errors. The first could also lead to issues with using controls that were created or added to the controls list on the fly. The second wouldn't work in that situation at all.
| |
If you can't handle storing this information, does that mean the library looks it up every time it needs it? That doesn't sound very effective. It also sounds like people using the library should have a better way to manage things than just this one controls list. You could easily provide some procs as the interface to the library so the internals can work however you need them to work and users have a simple and consistent way to use it.
| |
HDK Mouse And Keys
It works by having the developer store the name of the map control (soon to be expanded to all controls) so that the library can run everything through that. The only time the library needs the parent is for creating the browser control that runs the JavaScript. At that point, it queries for the parent and creates a browser control with all of the variables of the original control so that the JavaScript can simply reference it's own variables for it's calculations and the whole thing can be processed on the client's end. The developer has a few procedures for interacting with the library, though it seems I forgot to upgrade two of them in the last update. | |
So when the player calls a proc to initialize the mouse tracking, make them have to pass it the control ID and parent ID. That proc uses the parent ID instead of querying for it. It doesn't sound like it needs to remember it, so it doesn't complicate any of that other stuff.
| |
The entire point of the procedure is not having to know specifically what the parent, or any other control properties are.
| |
Hiro the Dragon King wrote:
The entire point of the procedure is not having to know specifically what the parent, or any other control properties are. I understand why that would make the library easier to use, but requiring that the developer specify the control's parent isn't nearly as much of a problem as you're making it out to be. If you change how the library works, people who use the library can easily update how they use it. You could also have the parent ID be optional and use the workaround if the parent ID isn't specified. That way there's the explicit, foolproof method and the potentially-incorrect workaround for people who don't update how they use the library. | |
I will let the procedure work as it does. I will not alter the way it should work because of a feature that the developers are either too lazy too unintuitive to add.
| |
Hiro the Dragon King wrote:
I will let the procedure work as it does. I will not alter the way it should work because of a feature that the developers are either too lazy too unintuitive to add. This is for the mouse tracking library, which exists "because of a feature that the developers are either too lazy too unintuitive to add." =) | |
Very nice. I guess I should think my posts through a little more. ;)
To be fair, this feature is infinitely less complex, and they almost, yet missed, added it in last year. | |
I was hoping that we may get the now that we could winget() the id of an element. Any particular reason it wasn't implemented from the get-go?