It would be great if Xojo had a ‘Hide Empty Events’ to the right click menu option.
Because of the lack of ‘bold’ text for events with code content it can be troublesome to see which event has code or not.
Best would be the inclusion of both:
In the old IDE if an event was empty it was a no-op. In the new IDE if a event is added, even if it does not have code it WILL be called in the executable… because of that it makes no sense to ‘Hide Empty Events’.
It does however make sense to bold events that have code in them…
You might add a bunch of events you intend to implement latter…
If Events with code were bolded, it would help you remember to implement the ones that are not, or if it turns out you did not need them to delete them.
Unobtrusive visual clues to state are good…
And to be precise, empty meant “no text at all in it”. If it contained a comment or even whitespace it got treated as implemented.
In Xojo Events have to be added manually.
Because nearly all the added events contain code, I would prefer not to show events with code in bold.
(Bold requires more space in the Navigator and that’s what a lot of people here prefer. 
)
Maybe showing the empty Events in italic is a better option.
And for the web it just has to exist - code or no code
The way it is now it’s more consistent between web & desktop apps
Couldn’t edit my reaction anymore, because there was a reaction added in the meantime. 
Should be: Bold requires more space in the Navigator and that’s NOT what a lot of people here prefer.
I understand all that … but here is a suggestion…
Once you have added an event… you have to manually delete it if you later decide to refactor and remove/move that code… but just removing the code leaves the event handler. How about making EMPTY ones show as RED… to give the developer an indication that they may wish to remove it.
[quote=24880:@Karen Atkocius]In the old IDE if an event was empty it was a no-op. In the new IDE if a event is added, even if it does not have code it WILL be called in the executable… because of that it makes no sense to ‘Hide Empty Events’.
[/quote]
Didn’t know that. I now sometimes just add all available events of a control (cmd-a). So I do not need to add them later manually.
Thats why I wanted to see the (hide all empty events). 
[quote=24885:@Dave S]I understand all that … but here is a suggestion…
Once you have added an event… you have to manually delete it if you later decide to refactor and remove/move that code… but just removing the code leaves the event handler. How about making EMPTY ones show as RED… to give the developer an indication that they may wish to remove it.[/quote]
Yes, that would be a good idea to do. You have my vote.
And what about a ‘Remove all empty events’ option?
[quote=24885:@Dave S]I understand all that … but here is a suggestion…
Once you have added an event… you have to manually delete it if you later decide to refactor and remove/move that code… but just removing the code leaves the event handler. How about making EMPTY ones show as RED… to give the developer an indication that they may wish to remove it.[/quote]
With code as bold or without as red… either would work equally well.
I suspect that If they were willing to to do that, there would not have been a need to change how it used to work (well except that it would make the navigator larger!!!)
I really don’t like having to add events at all… I hear the argument about the web edition but it it feels like a step too far in trying to save us from ourselves…
Personally I think that the argument that with the current navigator design (which I HOPE gets changed), having all events visible would make the navigator even more unwieldy is stronger (and fixable!!).
Events without code should be clearly marked. I don’t follow the “bold needs more space and that’s not what people want” suggestion. People want a useable IDE, with visual cues, and the extra space required by bold is negligable compared with the wasting of space elsewhere.
In Real Studio most of the Events didn’t have code and the Events with code were bold.
In Xojo the Events without code should very visible, not the Events with code, because most Events have code.
If all the Events with code in Xojo would be bold, then the Events without code wouldn’t be very visible.
To make the Events without code extra visible, I suggested italic, but I also like Dave’s idea to make them red.
Any suggestion to make the Events without code extra visible is fine by me.
It isn’t only web edition that optimizes for cases where there are no event handlers. For example, if you haven’t implemented the MouseEnter/MouseMove/MouseExit events, a tracking rect won’t be installed for that control.
But my point was why is not leaving the events empty good enough to not have them implemented- with bold as in indicator of implemented?
That was what I meant by saving us from ourselves a bit too zealously to prevent unintended implementation of events.
[quote=24905:@Karen Atkocius]But my point was why is not leaving the events empty good enough to not have them implemented- with bold as in indicator of implemented?
That was what I meant by saving us from ourselves a bit too zealously to prevent unintended implementation of events.[/quote]
Ah, sorry. I was apparently having a different discussion than everyone else :).
[quote=24905:@Karen Atkocius]But my point was why is not leaving the events empty good enough to not have them implemented- with bold as in indicator of implemented?
That was what I meant by saving us from ourselves a bit too zealously to prevent unintended implementation of events.[/quote]
If you can see it listed its “implemented” seems pretty straight forward
Presence / absence of code isn’t what determines “implemented” since the IDE cant tell if anything is “usefully” implemented or whether it’s 100% comments (or better yet all buried in #if pragmas) The compiler can but we don’t compile your code as you type.
[quote=24934:@Norman Palardy]For web edition there’s no clear delineation.
If the event exists but is empty does the server still send the event to the client or not ?
Does the client send it back to the server or not ?
[/quote]
That of course depends of course on how Xojo implements things. If it was codes like the old IDE teh answer of course would be no and could have been for the new IDE. Events with no code were not included in teh executable and it could have been made to work teh same way for the web.
I don’t follow the inevitability of that logic…
You obviously can send code the browser that has or does not have the events (or inactivates them). You currently decide what events to include by us adding them via the dialog… but logically at build time you COULD get the same info on which events to implement by checking if any text was entered into the event. Am I missing something?
I do…
But as far as I can see, all Xojo really needs to know is which events to implement at build time. It does not matter how you get that info as long as it is available at build time be it web or desktop. The old way gave you that info too.
BTW the reason I liked the old way better is because it helped me remember the specific of controls and learn new events when they were introduced … The framework is large and seeing the events made it easer for me to code, particularly for controls I don’t use often. And when I did not want to see them all the empty events they were easy to hide.
That said, with the current design of the navigator, seeing all events is not practical… but may it won;t always be that way…
[quote=24937:@Karen Atkocius]I don’t follow the inevitability of that logic…
[/quote]
Spend some time in the Chrome debugger and digging through browser-side source for web applications, and it’ll become pretty clear. It’s really just by definition. Not much logic involved. It seems like a reasonable enough design decision to make the boolean choice of event implemented or not at compile time rather than runtime.