Why does the message pane now close upon run ?

General
21

@Michel Bujardet :
I believe you misunderstood my comment.

Why not split the current and prior behavior depending on which pane you have open when you do a debug ‘Run’? This allows both uses without any new preferences.

If you have the search/error pane open, let ‘Run’ close it. At that point, you are probably NOT watching the debuglog. Otherwise, if the message pane is open, leave it open, and continue with your debug.

If you wanted the message log but left it on the search pane, you would STILL have to ‘click’ to open or switch the pane, whether it was closed or not.

Sometimes I use the message log, but more often I’m closing the ‘error’ pane to check how the app responds after cleaning up syntax/scope errors.

22

That’s an excellent suggestion, and quite logical. You should add that to the Feedback if you haven’t already.

23

[quote=245472:@John A Knight, Jr]@Michel Bujardet :
I believe you misunderstood my comment.

Why not split the current and prior behavior depending on which pane you have open when you do a debug ‘Run’? This allows both uses without any new preferences.

If you have the search/error pane open, let ‘Run’ close it. At that point, you are probably NOT watching the debuglog. Otherwise, if the message pane is open, leave it open, and continue with your debug.

If you wanted the message log but left it on the search pane, you would STILL have to ‘click’ to open or switch the pane, whether it was closed or not.

Sometimes I use the message log, but more often I’m closing the ‘error’ pane to check how the app responds after cleaning up syntax/scope errors.[/quote]

Fact is, the previous behavior was exactly that. If the Messages pane was open upon run, it stayed open. Now Xojo closes it. Kind of like a car that would close the odometer upon start.

In 2014R2.4, upon run:
If Errors is open, it stays open
If Search is open, it stays open
If Messages is open, it stays open

Since 2015R3, ALL panes are closed. I can understand for search and errors that are not necessary; but it makes absolutely no sense to deprive the user of DebuLog messages during a debug run. At least, it would make sense that if I decide to display the message pane, Xojo does not kick it to the curb.

Let the people who initiated this ridiculous FR use the IDE script instead of forcing us to do so.

24

Even though it didn’t quite sound it, I think you just agreed with John, no?

25

My first paragraph attests to it.

To clarify, pre-2015R3 left open any pane that the user had sovereignly decided to open for his own reasons.

Since 2015R3, in spite of the very toggled button at the bottom (toggle in my book means only a new click removes that option), Xojo decided to remove all panes.

I don’t mind that search and errors be closed upon run. I do find it stupid to close Messages. Might as well get rid of it entirely, and remove System.Debuglog altogether.

26

I think you might be exaggerating just a wee bit. :slight_smile:

27

I mind. If I opened it, it should stay open until I dismiss it no matter which pane it is.
With it closing on some panes but not others, that would create confusion for anyone who wasn’t explicitly aware of that behavior.

Either a sticky third button state, or a preferences setting needs to be made since we’ve all got varying methods of development, and y’all are doing it wrong :wink:

28

Moi ?
Never :wink:

29

Besides the preferences issue I wonder why the first call of System.DebugLog does not make the Message pane visible.

30

Hmmm… I hadn’t noticed this change until reading this thread. Now I wonder if this could be related to my crashes in 15r4; <https://xojo.com/issue/42068> (still open) and <https://xojo.com/issue/42374> (now closed).
Race conditions going on in the IDE?

31

42068 is more likely related to this: https://forum.xojo.com/29865-compiler-slowdown/p1

32

That would be swell. Actually, that would render justice to the messages mechanism. If not needed the Messages pane would remain hidden, but at the first DebugLog, it springs into action. You should suggest that at <https://xojo.com/issue/42441>

Not quite sure how easy that would be, though, since the message pane in that case should not open when it receives simply “myapp open” and “myapp closed”.

33

42068 has nothing to do with that

34

I would hate this. Let the user choose.

35

You guys need to re-open discussions on this.

36

If the message pane is open, it means I clicked the toggle button at some point. So although it was my decision, the IDE knows what’s best for me.

Running in debug mode means that I want to debug things. When the APP (normally) runs, there is NOTHING happening in the IDE except the System.Debuglog() messages are showing up. And yet, that pane is closed ‘for me’.

It just doesn’t make sense that IDE un-toggles the button/closes the pane. I toggled the button. I opened it for a reason.

So if the message pane is not opened automatically at each run, then at least; when the pane is open, it should stay open. If it’s closed, stay closed.

37

Exactly. Once again, the ugly face of “mother knows best”…

So now, we have to resort to using the Console and DebugView to see what is going on in our programs. I really wonder why they bothered building a message display pane to shut it upon run. Now you see it, now you won’t. Inconsequent at best.

38

Again, I like the new behavior so I wouldn’t want this to turn into a debate over who’s right, but rather an exchange of ideas.

Here’s another one. Since the issue is the space that’s lost for debugger, what if the pane closes the first time the app drops into the debugger on a breakpoint or break statement?

39

^ Perfect

40

[quote=245618:@Kem Tekinay]Again, I like the new behavior so I wouldn’t want this to turn into a debate over who’s right, but rather an exchange of ideas.

Here’s another one. Since the issue is the space that’s lost for debugger, what if the pane closes the first time the app drops into the debugger on a breakpoint or break statement?[/quote]

I agree entirely with the new behavior for errors and search, which have little to do during the app run. I believe it must be possible for the user to decide himself if messages are to close or to remain.