pane to window fails

Page: 1 2
ID:111853
 
Apr 10 2011, 12:53 pm (Edited on Apr 10 2011, 8:21 pm)
Not a bug
BYOND Version:480
Operating System:Windows 7 Pro
Web Browser:Firefox 4.0
Applies to:Dream Maker
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
Windows convert to panes but panes do not convert to windows

Numbered Steps to Reproduce Problem:
(1) Create a new environment
(2) Add an interface file
(3) Create a new window
(4) Check that it is a pane (not a main window)
(5) Click OK to accept the window/pane
(6) Reopen and click edit
(7) Uncheck the it is a pane checkbox

Expected Results:
The window reverts back to being a window not a pane

Actual Results:
Once you make a window a pane it is a pane forever

Does the problem occur:
Every time? Or how often? Always
In other games? Yes
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur?
When not needing to set a pane back to a window

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Currently untested

Workarounds:
Make a note of all window/pane settings, delete it, then re-create the window and restore all the noted settings.
Apr 10 2011, 1:24 pm
Seems to work fine for me, you probably just aren't re-enabling the titlebar and other related settings, which could/should probably happen automatically, but I'd think that's more of a feature request.
Apr 10 2011, 8:12 pm
It could be me maybe but why does it take the workaround...

In the reproduction steps I am simply toggling the checkbox. The other computers here exhibit the same behavior.

I suppose I'll go backwards in the byond versions to see if this is a beta bug.
Apr 10 2011, 8:23 pm
Falacy you were right about creating a new window and the checkbox toggling from window to pane correctly.

I have updated the reproduction steps to more accurately reproduce the issue. Each previous version I have tested so far has this issue.
Apr 11 2011, 4:57 am
This works for existing panes as well. I'll probably need to see a demo or a copy of the project this happens in. Code can be emailed to me in a .zip at [email protected].
Apr 12 2011, 11:48 am
Well it happens both in old projects or brand new ones. I am actually thinking about building a flash based demo in FRAPS to demonstrate. The machines here are Windows 7 variants so this may be a Windows 7 specific bug.
Apr 12 2011, 12:49 pm
I opted using cam studio for various reasons. I am not skilled with it's usage but was more focused on showing the bug in play.

The link contains a zip with html and swf:
http://www.zshare.net/download/889329682f229867/
Apr 12 2011, 12:58 pm
I can't get the download to work on zshare, and if I don't try to bypass its stupid JS it does a popup window and still doesn't work.
Apr 12 2011, 1:01 pm
I sent a copy of that same zip to your email Lummox. I'll scratch zshare off my list for a decent file sharing provider.

Any recommended alternatives for future reference?
Apr 12 2011, 1:03 pm
Megaupload doesn't suck. None of this type of site works for hosting BYOND game downloads though.
Apr 12 2011, 1:08 pm
I bookmarked megaupload and here is the new link for anyone interested in viewing this bug:
http://www.megaupload.com/?d=2XJ31ARU
Apr 12 2011, 6:10 pm
I looked at your .swf file and I see no evidence that the pane checkbox is failing to reset. After you turned off the pane setting, you never opened the window's settings back up to show that it didn't take.

What I did see was that you moved the mouse around as if to point out the window style--this is not the same thing as the pane setting not resetting. What it shows is that styles that were turned off when the window was changed to a pane were not automatically turned back on. If that's all there is to this, then this isn't a bug.
Apr 12 2011, 6:23 pm
Well I admit that I did not do a runtime test but the controls in the edit panel/window reflected that the settings went back to a window.

I could indeed have been mislead which means this is not a bug indeed. Visually speaking, the pane/window which is supposed to reflect what is seen in the game, well, it is misleading. I'll do a runtime test to see if this is just a visual issue.
Apr 12 2011, 6:34 pm
Here is some runtime screenshots:
http://www.megaupload.com/?d=JLZEYET0
Apr 12 2011, 6:39 pm
To be honest here, now that I think about things, it seems that I am being singled out. I am not reporting this to cause BYOND more work.

Actually between the screenshots and the flash video I took the time to make it was a legitimate report.

I have corrected the reproduction steps, made a flash video, and just now followed up with screen shots. How is that -NOT- a bug!?

If my bug reports are unwelcomed then fine. As painful as it is to learn I may be better off with something like C plus plus anyway. Sorry I wasted both of our time.

EDIT:
The other bug I am referring to is:
http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=2434

And the fix that *I* came up with to fix that bug is:
proc/UpdateUserlist()
    //Bug fix (User Count somehow desyncs (internal to BYOND))
    var/curUserCount=0
    //Update allusers list (sorting)
    var/list/allusers=list()
    //First we'll loop users adding the active ones
    for(var/mob/LM)
        if(LM.client)
            curUserCount++
            if(isnull(LM.icon_state)) allusers += LM
    for(var/mob/LM)
        if(LM.client && LM.icon_state=="away") allusers += LM
    //If we somehow got desynced then re-sync clients count
    if(curUserCount != clients) clients = curUserCount
    //Now let's do our updating
    for(var/mob/LM)
        if(LM.client)
            winset(LM,null,"userlist.cells=2x[clients];cusers.text=\"Users Online: [clients]\"")
            var/ultracker=0
            for(var/mob/ALU in allusers)
                if(ALU.client)
                    ultracker++
                    LM << output(ALU,"userlist:1,[ultracker]")
                    if(!isnull(ALU.awaymsg)) LM << output("<font color=#808080>[ALU.awaymsg]</font>","userlist:2,[ultracker]")
                    else LM << output("","userlist:2,[ultracker]")


That being said I am done wasting my time and the time of everyone else here. I absolutely love BYOND as a language, it's easy and fun. This is bull****
Apr 12 2011, 7:02 pm
I'm not singling you out or anything; the only reason I didn't wait to see the screenshots is that you already confirmed in your previous comment that the issue isn't occurring as reported.

What you reported was that after changing a window to a pane, it cannot be changed back to a window. But in subsequent testing you confirmed that turning the pane setting back off does work; only the rest of the window styles aren't resetting. The issue that was reported--the pane setting not changing--is not happening. That's why I closed the issue as not a bug, because converting a pane to a window is working, it's just that the specific window styles like the titlebar and such don't come back, which isn't the same thing.

While I do see how the styles not coming back on automatically could be an annoyance, there's nothing inherently wrong with the current behavior. The styles can be turned back on manually, and honestly it's not that common that an author changes a pane to a window in the first place. Making this happen automatically would belong in a feature request.
Apr 12 2011, 7:16 pm
Regarding issue 2434, the fact that the bug simply couldn't be reproduced meant the issue couldn't even be investigated. There were no numbered steps to reproduce the problem, nor was there a demo that produced the problem on a reliable basis. As I mentioned at the time, normally such a bug report goes in Unverified but there wasn't really enough substance to ever follow up on it. It's definitely the sort of report that's on the borderline, but whether it sits there forever due to being closed or due to being impossible to reproduce, it's the same either way.

Please understand, this is nothing personal. A bug report that has no information that can be used to reproduce or investigate it is basically stillborn. And this issue is just a case of miscommunication. You meant styles but said pane, and the former isn't a true bug while the latter is performing as expected, so the report would have been closed in either case. But I've put in due diligence in investigating this issue, and I fully acknowledge that you have done your best to help by providing the video. The video provided the clues we needed to move forward, by exposing the fact that we were talking about two different things.
Apr 12 2011, 7:27 pm
I feel very much singled out. But disregarding issue 2434...

How is -this- issue not a bug? If the intention was to purposely allow unsetting visual style but keeping a window, then why is there not a checkbox that states such?

In my opinion this is very much a bug in the given design it was reported in because whether internally or not, the minimize and other such buttons do not actually apply.

I won't deny that there is a way via DM code to achieve getting it back even though I have not tested that statement, nor will I deny that this behavior could be seen as a caveat in certain circumstances.

I feel that without the allotted checkbox to toggle visual styles, in the current context, this is indeed a bug. But that is not my call to make.

I apologize for my outbursting and hope you can understand where I am coming from. I seen an issue and thought that the right thing to do was report it.
Apr 12 2011, 7:55 pm
I'm sorry you feel singled out, but I can't help that. I've closed a lot of other issues as non-bugs over the timespan between 2434 and now; this is just normal maintenance of the list. I closed the issue only for the reasons I mentioned. The fact that you reported what you saw as a bug is still appreciated. To be honest if it wasn't for the fact that the literal text of the report refers to the pane setting itself rather than the window styles, I'd be tempted to just move this to Features.

Hopefully this will clear up any confusion on the pane setting and why the styles are acting the way they do: Whether a window is a pane or not is not, strictly speaking, a visual attribute; it's a behavioral one. Windows can only be used as standalone windows, and panes can only be used within a child or tab control. The window styles on the other hand are mostly visual rather than behavioral (though some, like the close box, dictate how Windows handles them on the taskbar), but because they are irrelevant to panes, panes always turn them off. It is possible, and some authors even find it desirable, to have a window that has no titlebar, is not resizable, etc., and turning them all back on at once when converting to a window would probably be considered just as undesirable, by some, as the fact of leaving them all off.

Leaving the style settings on or off internally, so that they return to their previous values when you uncheck the "is a pane" box, may well be feasible; it probably just requires a few things to change here and there under the hood. Again I don't regard the current lack of this as a bug, just a missing feature; having them just turn off is a pretty reasonable option for the 99% of users who will never turn the pane checkbox back off. But don't get me wrong, I do understand where you're coming from on that, and honestly this wouldn't be the first time a user has had a different opinion than I did as to whether something was a bug or a missing feature. Heck, even Tom and I don't always see issues the same way, though he has final say as to how anything is classified.
Apr 12 2011, 8:08 pm
Lol Lummox alright. I gave it some thought and after playing around more locally I can see your point.

Would you move this to feature requests providing a way to get the visual styles back? Maybe, you may want me to file a feature request on this?

I sincerely apologize for the misunderstanding. And thanks for explaining things when you could have ignored me.
Page: 1 2