Zugg Software :: View topic - [1.34] Setting editor's Refresh button/menu item doesn't

Adept Joined: 04 Feb 2005 Posts: 246

Create a variable either in the editor or via the command line, then click on it in the settings editor. Then change it via the command line (e.g. #VAR tmp 2). Using refresh will not update the display of its value. You have to click a different setting then click back on the variable to see its new value. In zMUD, refresh would immediately update the view.

Posted: Thu Aug 16, 2007 4:52 pm

I'm not sure if this is a bug, I think it's by design.

The idea behind is since everything is DB driven when you have a setting highlighted, you could be making changes to that variable, setting etc that you wouldn't want to be lost because of a background update. When you click on another setting without any changes made (then there is no save done) and when you go back to your variable again, you see whatever is in the in-memory DB. If you had made changes these (I believe) would overwrite whatever background updates may have occurred.

One could argue that by clicking the refresh button you are either discarding or automatically saving whatever changes are made, but I'm not sure I agree with that. I think this boils down to what Zugg thinks and if he explicitly did it or not.

Posted: Thu Aug 16, 2007 11:12 pm

Tech is correct. It's not going to update the variable if you are currently editing it. People would be *really* annoyed if you were editing a script and then a trigger fired in the background causing the item you were editing to change and you lost all of the edits that you were doing.

Refresh will update the value just fine if you are not editing the item that changed.

Adept Joined: 04 Feb 2005 Posts: 246

But by clicking Refresh, I'm asking to see the current value. Since clicking on another setting automatically refreshes the display, what's the point of the button/menu? Maybe there's something that I'm missing here? I'm just used to the zMUD behavior, which is what I want.

And now, say you are editing a variable that has gotten updated by triggers. Wouldn't it make sense to hit the refresh button to get the current value, rather than thinking what you editing is current, and then overriding what your scripts have updated it to?

And to an earlier point, if you are editing a setting and then click on another, it looks like a save is done for you.

Posted: Fri Aug 17, 2007 1:14 am

Possibly. The current Refresh command just calls the same routine that is also called by the background updater. That's why it doesn't refresh the currently edited setting (because you don't want the background updater to mess with what you are editing). I suppose I could change the Refresh button so that it also refreshes the current setting as well. I'll consider that. The main reason for the Refresh command at the moment is for internal debugging since the TreeView can sometimes get out of synch with the database and Refresh will fix that. With the auto-update happening in the background, Refresh isn't really needed (except maybe to force the current setting to update like you are asking).

And yes, if you are editing a setting and then click another, CMUD always saves. This is the way most database programs work. I never want you to accidentally lose a lot of editing work, so CMUD always saves what you have edited, whether you click another setting, or close the window. To cancel your edits you need to specifically click the Cancel Changes button.

Adept Joined: 04 Feb 2005 Posts: 246

By the principle of least surprise, and by what zMUD used to do, I'd vote for having Refresh update the current setting in the editor. Otherwise, I'd call it something else, and not make it a prominent button on the UI.

Magician Joined: 13 Oct 2000 Posts: 463

I agree with Zhiroc.