ID:96621
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
I propose a tooltip function should be implemented into a future BYOND update. Also it couldn't be just a static unchangable blob that pops up onscreen, but have variables that allow for more flexablility such as boarders, boarder size, border color (based on hexadecimal color pallet), title, tangablility, alpha settings, font (based on computers default font set), font size, font color (again based on hexadecimal system), size, scaling options, and shape. This may seem like a lot of information but it would greatly help in the display of information and the playablility of games made with BYOND. I can see almost every game using this in it at some point or another. As said by a roman leader(can't remember which one), "If you build it, they will come."
The phrase you're thinking of is "If you build it, he will come" and it's from the movie Field of Dreams.

I do like the idea of adding tooltips to controls, although our approach with such things has always been to follow the KISS principle whenever possible, so giving the tip a custom color, borders, etc. probably isn't worth it. A standard Windows tooltip would still be an improvement and it could be handled with a simple string.
I have wanted tooltips in BYOND, even very basic ones, for the longest time.
I agree, this would be great. I've seen some forged tooltips (some screen objects, iirc, or maybe it was a large label?), but a better tooltip would be great, as we'd be able to control it that much better.
When you hover over a control on a 'special spot' for a while, (or possible click it with shift or something), a tool tip balloon thing comes up....
the stuff in the balloon can be changed by a new parameter, "tips" or something, it could be text, html, or another control.
i'm sure it could be used for a number of purposes.
In response to Super Saiyan X
This should be developer implemented through MouseEntered/Exited (which still needs to be added for controls)
Though, I wouldn't mind having a way to do this in an output, through some sort of custom HTML tag.
In response to Super Saiyan X
To be honest, I would like to see interface interactions able to be handled via code, more than the interface editor.

What I mean by this is a small example:
interface/map/mainmap
// /interface is the datum handling all interface interactions. This is built-in.
// /map is a sub-form of /interface which is also built-in.
// mainmap is a user-created object that the compiler will check if a map with the ID of "mainmap" exists.

interface/map/mainmap
tooltip(client, element, parameters)
// tooltip() is a built-in proc that does what the OP asks for.
// client is the /client parameter needed.
// element is a created element, similar to winclone(), but requires information such as GRID, MAP, LABEL, BUTTON, etc.
// parameters are extra parameters to adjust/customize/alter the element.
// How tooltip() would most likely work is it builds a new movable window for the interface which will take the element parameter, and create the element inside the newly created window. From there, it will grab the extra parameters which can be, for example, parameters to adjust a button to stretch-to-fit the window and make the button blue with white font.


From there, the newly created button can be created similar to how mainmap was made.
interface/button/mainbutton
// or
var interface/button/mainbutton = new()


That way, the button can be referenced and altered via code to adjust the settings such as command, height, location, color, etc.

Hope that was detailed enough, but that's how I would dream of this happening.
In response to Super Saiyan X
If you only want these for a map, then that's already completely do-able. Just build the tool-tip for mappable atoms.
If you want it for an actual interface control, like a button, then you have a problem, because mouse procs don't work for those.
In response to Super Saiyan X
Falacy wrote:
If you only want these for a map, then that's already completely do-able. Just build the tool-tip for mappable atoms.
If you want it for an actual interface control, like a button, then you have a problem, because mouse procs don't work for those.

Hence my suggestion below.
In response to Super Saiyan X
Maximus_Alex2003 wrote:
Hence my suggestion below.

There's no point in them creating a system that does nothing but display tool tips. Presumably, it would need some sort of mouse-over detection anyway, it most likely wouldn't be much more effective or efficient for them to implement than for us to make on our own (once mouse functions on controls exist), and in the end it would work almost exactly like winset() does now - based on your tooltip() suggestion.
In response to Super Saiyan X
Maximus_Alex2003 wrote:
To be honest, I would like to see interface interactions able to be handled via code, more than the interface editor.

Then check out my interface library. Among other things it defines object types for each control so you can create an object to represent each control. Almost any property can be set or read by calling a proc. Instead of winset(src,"label1","text=hello") you can do label1.Text("hello").

Falacy wrote:
There's no point in them creating a system that does nothing but display tool tips.

The controls have support for tooltips already, the staff would just need to create a property to expose what your OS/desktop environment already handles. It would be limited to plain text but it could be implemented client-side very easily without needing mouseover events.
In response to Super Saiyan X
Bump.
In response to Super Saiyan X
DivineTraveller wrote:
Bump.

wut. do you bump cause you support?
also, would this by any chance help:
http://www.codeproject.com/KB/miscctrl/pptooltip.aspx ?
Bump? It was mentioned that even a simple one was possible, and that's preferable to nothing.
i request the same thing, too.
http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=2236
totally mark mine as a duplicate, and look at the comment i posted wif a fancy link. ok.
As I stated in the other topic that was linked to, adding specific systems for this would be somewhat pointless, especially with the degree of customization you're requesting. We can easily make our own systems for this, providing the exact functionality and customization we require. The only problem is the lack of mouse functionality on interface controls, which is what should be added, for multiple reasons aside from just this.