Zugg Software :: View topic

Posted: Thu Jun 26, 2008 9:27 pm

I am moving the discussion of MXP FRAME problems and suggestions from the big topic here: http://forums.zuggsoft.com/forums/viewtopic.php?t=31101

I have played around with frames and was able to verify the problem with the size of frames being reset if the window was closed and then opened again via the frame command. In other words, if you did this:

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

It's a bit awkward participating on a forum that isn't all about user's flaming each other.. It's really quite a unique experience for me to be able to make a post and have it actually listened to, much less have my ideas implemented, especially so quickly. So basically, I guess that's just a big 'Thanks!' n.n

Anyways, I really appreciate these fixes and added functionality. I really ought to be able to do what I want with frames for the most part, regardless if the user is using zmud or cmud, which is great. I intend to support Pueblo, ZMud and CMud to the levels I can manage for each, so this is great news for me, as CMud is the most advanced of any of them.

Another thing I mentioned that you haven't yet mentioned is the ability to put 2 frames into a tab together. If you'll look at my image in the last thread for my CMud frame layout, you'll see that I have one particular frame (Container, perhaps? I'm not sure what you'd want to call it..) with 2 frames in tabs. One tab is the room descriptions and the other tab has 2 frames inside of itself: Map and Map key.

Perhaps:

Posted: Fri Jun 27, 2008 8:25 pm

Yes, you can put two frames into a tab together. The syntax is this:

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Ahhh.. Very nice.. I didn't realize that the 'client' docking option would work that way.

Also, I do remember seeing something about the persistent tag somewhere at some point but at that point in time I didn't understand it. But yeah, if it behaves like you say it should in the next version, than that pretty much negates my ideas on any such override tag.

About the tick timer, I tried what you said on escaping out to the default window and yeah, it is running by default. I don't have any problem with deleting/renaming the default package, I'm just curious as to how this came about being set in the first place. The only way I can think of is when CMud imported by ZMud settings. All I know is I never set it that way by default.. :P I just renamed my default.pkg and am currently waiting to see if it fixes the problem.. And... It seems to have worked.

It really sounds like frames will work the way I need them to in the next release, so I'd say I'm pretty well satisfied.

And I know how you feel about documentation. It's never been my strong suit either. I can -do it- well enough, I just don't like to when there are other things that can be done that are actually productive rather than aesthetic.

Another thing I've noticed is that when using the command to try to close a frame, the frame just goes blank but doesn't actually close. Is this intentional or will it be fixed?

Also, I'm not sure if my previous mention of <frame action="redirect" name="_previous"> not working ever got heard. A minor thing that I am currently working around by just using <dest> but it's a bug nonetheless I think. "_top" also doesn't work, but I don't think it ever worked in ZMUD either. I always had to use _previous and make sure that my framing was handled in such a manner that _previous always put it back to the top window.

Addendum: I'm pretty sure I mentioned this before, but another thing that mildly irritates me, but is mostly a user-error sort of thing.. When you have frames open and you are for whatever reason, inside of one of those frames (I.e. you clicked a tab in one of them and it swaps CMuds focus to that frame) any commands sent through are sent to that frame instead of the main MUD window. I can see where this might be intentional in some cases, but in my particular implementation of frames, it does no good. The commad is shown on the frame and nothing happens since it was never actually sent to the MUD.. Just nitpicking I know, but in this particular scenario, I don't see why the command wouldn't just be sent straight to the MUD window.. (I'm referring, of course, to using keypresses, since these frames clearly don't have command lines.. For example, using the numpad to get around.)

Edit: That last point I brought up gives me a unique idea that is possibly once again, wishful thinking. Perhaps when a frame is created, the player/server can specify a tage as to whether or not to show the command line and what it prefixes when sending the information to the MUD.

Posted: Sat Jun 28, 2008 5:20 am

Glad to hear you found the problem with the tick timer. Not sure how it got that way. As you said, it's actually very hard to change the tick timer option in the default settings. CMUD no longer ships with any predefined DEFAULT.PKG file, so it must be something left over from the past. If you ever figure out how to make it happen again, let me know.

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Ah, another thought I had that would likely make everyones lives a bit easier and also help with the whole issue of MXP created frames overwriting each other. (Assuming you don't go with the whole 'Don't allow MXP to change my settings for this frame' option I suggested in the package editor for the specific windows.. Or even if you do..)

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Something else I just noticed. Images used in the main window are found in/saved to 'C:\CMUD\<Mud name here>\images' whereas if they are called from within a frame, they are saved in 'C:\CMUD\images' (These are just example paths, obviously) It seems to me like you'd want the images being used by that specific MUD to be called from and saved to the images directory FOR that MUD. I tried looking through the individual window options for a place to set this directory and found nothing, so there seems to not even be any user control over this.

The main issue it would cause is if you use certain images in both the main window as well as MXP created windows. You'd end up with 2 copies of the image on your local hard drive.
Also, if the player played multiple muds that support images (Or even just use images for themselves via the #MXP command), there might be some conflicted interest if they use similar file names. Something that 1 player in a million might run across, so it's not a huge deal.

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

I just found out why the frames aren't saving their sizes/positions when you close out of the session. (Granted, you may have figured this out for yourself already) When you just close out the session, it doesnt save anything. But if you go to Layout->Save Session Layout, they will be saved next time you start up. Apparently the Auto-Save layout option doesn't work. (Which I'd already realized, but didn't realize that it had an effect on frame positioning/etc.)

Posted: Tue Jul 01, 2008 5:28 pm

I couldn't reproduce the problem with the layout not saving, or with the Auto-Save layout not working. If the Auto-Save layout is enabled and I exit CMUD, then my frame layout was properly saved and restored when I opened the session again. So I guess I'll need an exact step-by-step procedure to reproduce that one.

On the frame focus issue, yes if you manually click on a frame, then the frame gets the focus. I can't actually do anything about that. A frame is a Windows object, just like an edit box or a button and when you click on anything like this in Windows, then Windows gives it the keyboard focus. If I mess with this, then you won't be able to click on a frame to undock it, resize it, or anything else. What was fixed in 2.29 is that sometimes CMUD would try to give the "current window" the keyboard focus when closing other windows, like the package editor. CMUD has a general routine in it called "UpdateFocus" that gives the command line the focus, and this is no longer called for windows that do not have a command line. But that doesn't prevent Windows itself from giving the frame the focus with you click on it. Sorry there isn't much I can do about that.

On the issue of the FRAME OPEN causing existing frames to resize, yes, that is actually a feature. If you only want your size/position information to be used the first time you *create* a new window, then use the PERSISTENT option for the frame. Although as I mentioned, this is currently bugged in v2.29 and fixed for v2.30.

The problem with the image directory storage is that CMUD allows multiple sessions and it isn't probably assigning your frame to a specific session. I'll see if I can fix that so that an MXP frame is properly associated with the correct session.

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

I'm not sure how to give a step-by-step procedure that isn't already obvious for the layout issues. If I open a frame in a session (Any session) and resize it/place it somewhere/whatever, then close out of the session, it reverts back to where it was before UNLESS I manually tell it to save session layout. This happens to me in v 2.29 on any of the 4 different computers I've tried it on in any session, regardless if it's an opened session or newly created session. If it's working for you, I'm just not sure what's going on in all of the different computers I use that tend to cause this.. I'll give 2.30 a try when it comes out with high hopes that it'll fix it by itself and try to come up with some more detailed information if not.

As the for the focus issue, I understand what you are saying. Perhaps this can just be fixed in the future with the 'prefix' option we discussed before by allowing any commands sent into that window to simply instead be redirected to the main window. So that it doesn't necessarily have to lose focus, but a window with no command line or active connection in it really has no need for accepting commands/macro keys.

As for the open bug, I'll just either go with the persistent option or rewrite my MXP coding so as not to open already opened windows. This is where that 'query' action I was talking about for the frame element would come in handy. The MUD can check the client to see if the window is already open and if so, ignore it or send the "OPEN" command if not.

Posted: Tue Jul 01, 2008 8:04 pm

OK, we'll wait till 2.30 on this one. It's possible that I can't reproduce it because it's already fixed.

The "query" option is an interesting idea for the future of MXP, but not something I'll be able to do for 2.30.