Is there any technical reason for the Message pane to be closed when a project is run in 2015R4, or is it some kind of regression ?
I think it makes more sense that if the user choses to display the message pane, it should stay right there.
I just worked on 2014R1.1 and 2013R1, where once the Messages Pane is displayed, it does not go away. That was much better.
Bummer. It should be optional.
Thank you anyway.
On Mac an IDE script can reopen it. On Windows the same script simply does not do anything.
I’ve found it quite annoying as well. It’s more cumbersome than helpful. Close find and errors - I suppose. Close messages - dammit, I was looking at that!
What I find extremely surprising to say the least is that the decision to implement was taken after only one guy asked for it.
This is to show how futile it is to believe in the ranking system. Was it even ranked ? 1,999 ?
To be fair, what that one guy asked for was a preference. But yes, to me, this “feature” seems poorly considered.
It’s a LAZY bugfix. Instead of actually fixing the problem, they just close the pane.
And if you report it, they close it as a duplicate. Claiming it’s by design.
Why should we have to set up an IDE script because Xojo is too lazy to fix a drawing bug?
Also: That’s not the case it was for. This is the one: <https://xojo.com/issue/30860>
it was actually both
we discussed a preference about this and decided against adding more preference settings
If no settings, then don’t break the camel back.
I regret that it was decided to change a default behavior that had been here since 2013R1 without a larger consultation.
Should we now file a feature request to repair that ? How many points will be necessary and how many people ? Two ?
A weird decision. To say the least.
<https://xojo.com/issue/41490>
<https://xojo.com/issue/41918>
With a tiny more thinking, everyone would have been happy. If the buttons at the bottom where toggled (for example) then leave the window as it is.
Just to throw in an opposite view, I’m pleased this was changed. It was quite annoying dropping into the debugger just to find that the bottom pane was still open and taking space from both the debugger and my code view.
Here’s the problem. Most of the time, I don’t notice the change at all. But when I’m actively trying to use the messages pane, the change is infuriating.
I think what this really demonstrates is that the messages pane is in the wrong location. I don’t have a better idea, especially considering I’m the one that put it there in the first place.
A floating Messages palette?
I usually just keep Console open if I need those anyway.
Now THAT is a rich idea ! Thanks Marco.
42441 - Make the Message pane button/icon toggled to prevent it from retracting when run
Status: Needs Review Rank: 638th Product: Xojo Category: N/A
Michel Bujardet Today at 10:16 AM
Since 2015R3 the message pane is automatically closed upon run. While some people apparently like it, it has become annoying to have to reopen the pane to see the messages, especially when one needs to see what is going on at the start of the program.
Why not make the button lockable, preventing the pane from going away at each run ?
One click, pane appears, will go upon run.
Second click when pane is displayed, button goes toggled, pane is locked in and won’t go away.
Third click, pane goes away.
That should satisfy all without requiring extra preference settings.
<https://xojo.com/issue/42441>
You may want to put points on that to show your interest into having again the message pane displayed during debug, as it would seem natural for such a tool.
decided against adding more preference settings
Are-you telling that you do not want to add new preferences settings (if so why) or just in this case ?
[quote=245288:@Emile Schwarz]>decided against adding more preference settings
Are-you telling that you do not want to add new preferences settings (if so why) or just in this case ?[/quote]
That isn’t what I wrote at all
We will add new preferences but we’re VERY choosey about what and when we add them
Our discussions ended with not adding a preference for this
[quote=245326:@Norman Palardy]That isn’t what I wrote at all
We will add new preferences but we’re VERY choosey about what and when we add them
Our discussions ended with not adding a preference for this[/quote]
Just backing up what Norman has said. We were always very choosy about what gets a preference, and I have no reason to believe that attitude has changed in recent years. Too many options become daunting.
Not asking for a paradox of choice in the preferences either. I believe something like a three state button as what I put in the FR above is an elegant solution. It should even be not too heavy to implement.
i’m constantly closing the search/error pane when debugging, so I like the auto close.
What about auto close unless Messages is open?
[quote=245437:@John A Knight, Jr]i’m constantly closing the search/error pane when debugging, so I like the auto close.
What about auto close unless Messages is open?[/quote]
The whole point of debugging is to be able to see the messages from the start go. Of course, some people do not even know about System.Debuglog so they would never see what Messages are for.
At the moment, since 2015R3, if messages are open, when one hits run, it closes it.
What I and several other need, is a way to prevent that, so we can actually DEBUG using debuglog. I suggested a three state button.
At this moment, the only way to do that is to use Console on Mac, DebugView on PC, or a an IDE script on Mac to reinstate the pane. Which is impossible on PC as it does not work (probably a bug but at this point it gets tiresome). This is ridiculous.