ID:1296524
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
It is currently impossible to access default macros and menus at runtime, without already knowing their names.

For example, if you create a new project and run this code:
mob/verb/Dump_Commands()
world << winget(usr, "macro.*", "command")
then you will get no results.

What I would like is if that would return about the same thing that this does:
mob/verb/Dump_Commands()
world << winget(usr,
{"macro.CENTER+REP;\
macro.NORTHEAST+REP;\
macro.SOUTHEAST+REP;\
macro.SOUTHWEST+REP;\
macro.NORTHWEST+REP;\
macro.WEST+REP;\
macro.NORTH+REP;\
macro.EAST+REP;\
macro.SOUTH+REP;\
macro.F1+REP;\
macro.F2+REP;\
macro.SHIFT+F2+REP"}
, "command")


I'm not sure what would be the best way to make that happen. From what I understand, either the wildcard format needs to check for names after ids, specifically for the macros and menus, or the ids of macros and menus need to default to their names.

I think if something like this were done, then the wildcard would be more consistent in what it's supposed to do.

I find it annoying and buggy that I can't programmatically access macros and menus without ids (at least without brute forcing lol). I almost decided to make this a bug report until I found this one.

Lately, I have been working on runtime interface generation, and for that to be complete, I need to get access to all interface elements without actually knowing what they are at compile time, so I hope this can be fixed.
If they have no ID, how can they be referenced? They need an ID to interact with them.
Lummox JR wrote:
If they have no ID, how can they be referenced?
That's why I made this request. The key here is that I would like to be able to access ALL interface elements. I just can't pinpoint exactly what needs to be changed in order to make that happen, which is part of why I made this request.

They need an ID to interact with them.
That's not 100% true. Let me quote the Skin Reference:
If a macro does not have an ID, you can refer to it by its key combination. If you have a macro set named macro1 and have a Ctrl+E macro for instance, you could use winset() with "macro1.Ctrl+E".
My second verb snippet above takes advantage of this trick to simulate the results I would like to get from the first example.

However, this trick only seems to work with macros, not menus, even though it would be nice if it did.

Since macros can be referenced by their key names, this tells me that it should be possible to add a way to loop through and grab all existing key names some how. If that is not possible, and BYOND is internally blind to all elements without IDs, then I would suggest requiring the IDs and making the compiler or Dream Maker automatically fill in any blank IDs it finds.

For example, if a new menu or macro element is left with no ID, then as soon as you hit compile, the ID gets filled in with some combination of name and command, such as: default elem ID = "name(command)". This is just an example. I don't know what would be the proper default ID format to use. If this format was used a default ID would look like this: CENTER+REP(.center). This should help ensure that the IDs end up unique. A check could be made for duplicate menus or macros (more than 1 with the same exact name and command) just to be sure. I don't really care how this is done, as long as it gives the wildcard something to reference.

Hopefully this describes what I am requesting here. Either I need a way to reference elements without IDs, or all such elements need to actually have IDs enforced, so that the result is all elements can be accessed at runtime.

These spooky elements are trying to go anonymous in my project and I don't like it!
It wouldn't be on compile as user defined skins are not compiled - but maybe on runtime it could add a pusedo-random id to any elements that do not contain one already.