I wasn't sure if this applies to the language itself or if it's a Dream Seeker issue. Either way, I find this to be quite strange, and I'm 90% sure there is a bug at work here.
I can easily make new menus or macros using winclone(), so I was sure that I could remove them just as easily by setting "parent=false", which works for every other element, but no, apparently the interface has other ideas. Trying this on a macro set just fails silently, but if you try removing a menu, then Dream Seeker will just crash altogether! This issue could in fact be a multifaceted one.
It seems like the deeper I go into the interface, the more buggy it gets. Honestly, I am expecting to find a lot more of these sort of bugs, since I am marching into uncharted territory with dynamically generated interfaces.
Numbered Steps to Reproduce Problem:
1. Create a new evironment.
2. Paste this code:
mob/verb
Clone_Menu()
winclone(usr, "menu", "menu-clone")
Remove_Menu()
winset(usr, "menu-clone", "parent=none")
world << winget(usr, null, "menus")
3. Compile and run the project.
4. Press F1 to open the "Options and Messages" window.
5. Click "Clone Menu" once in the verb panel.
6. Click "Remove Menu" once, and observe that the menu is still listed in the output.
7. Click "Remove Menu" a second time and receive the message "winset: Element menu-clone not found.", in Options and Messages, which is in contradiction to the output, where the menu is still listed.
8. Finally, click "Remove Menu" a third time, and watch Dream Seeker crash!
The above 3 strike crash seems to be the case for brand new environments, but in some projects, the crash just happens immediately.
Expected Results:
The cloned menu is removed from the world and all goes well.
Actual Results:
The cloned menu fails to be removed, Dream Seeker tries to tell you it was, and the whole thing just ends up crashing.
Does the problem occur:
Every time? Or how often?
Every time.
In other games?
Possibly.
In other user accounts?
I would assume.
On other computers?
I would assume.
When does the problem NOT occur?
When you give up and pretend that the bug doesn't exist! lol
Did the problem NOT occur in any earlier versions?
I don't think the interface has been changed in any recent versions.
Workarounds:
Use winset() to completely reset the interface: winset(usr, null, "reset=true") This seems to be the only way to actually remove a cloned menu, even though that completely defeats the purpose of trying to change only a single element.
Hopefully this gets fixed. I'm not totally sure if you are supposed to be able to remove cloned menus or macros like that at runtime, but I would like it if you could, otherwise they could just build up forever, slowly taking up more and more RAM as new elements are generated.
