Add All Default Events to Controls Automatically?

Is there any way to have all the default events automatically added to each control as opposed to having to do this manually? Having used previous old versions of RB I am thinking that having to manually add these, even in bulk to each control, is going to slow down the work flow as I was used to dragging a control onto the window and its already good to go as opposed to be fortune-teller as to what I may need in regards to events I may need later.

2014 1.1 Demo

‘the old way’ added maybe 2 lines of code to each project per event.
and if they were empty, I would expect (haven’t tested) that these methods would compile away to nothing.

Id have preferred a mix:
Add a control, get a bunch of typical events.
If you populate these, they produce compiled code.

At any time, one IDE menu item to ‘remove empty methods’ would reduce the size of the source code without breaking anything, if you wanted to tidy things up a bit.

I actually prefer the current way of adding in events. All the controls i used has been subclassed so most of the standard code is locate in the subclassed control.

[quote=145121:@art ouette]Is there any way to have all the default events automatically added to each control as opposed to having to do this manually? Having used previous old versions of RB I am thinking that having to manually add these, even in bulk to each control, is going to slow down the work flow as I was used to dragging a control onto the window and its already good to go as opposed to be fortune-teller as to what I may need in regards to events I may need later.

2014 1.1 Demo[/quote]

Having all the events cluttered the RB way and wondering which one has code in it is kind of cumbersome. Selecting only the few events that really are useful seems cleaner to me. If you have several controls that use the same set of events, simply duplicate the first one with all its really useful events.

I, for one, prefer Xojo over RB, although I have used RB and RS since 2002. But given the excellent level of compatibility with legacy code, nothing prevents one from using RS to code, and then compile with Xojo. I kind of remember reading here that several people do that.

BTW, you should avail yourself of 2014R2.1, currently available. If fixes a flurry of bugs still present in 1.1.

My other half prefer to use RS for screen design and doing tab order while i use Xojo to write codes.

Keep in mind that having a method appear in the Navigator means that it is technically implemented. That means that even if there’s no code, it will still be called at runtime. On the Desktop, you may not see much of an impact unless your app is particularly CPU intensive, but on the Web you will cause the amount of traffic to skyrocket. The Web framework is literally designed so that unimplemented events are not sent from the browser.

Take a WebButton for example… If you don’t add the Action event, when a user clicks the button, there is literally no traffic between the browser and your app, but as soon as you add the event (or use AddHandler starting in 2014r2), user clicks start being sent. Now clicks are pretty benign, but controls that send a lot of user feedback events and data could have a huge impact on performance as your app literally has to respond to every event. Not your code per se, but the framework has to take every HTTP request, parse it and route it to the correct control. That takes valuable CPU time and every additional session just adds to the load.

I don’t really think that is an option for things that didn’t exist in rs. One reason I was looking at xojo was for the newer picture class as my latest project works with batch png image processing which is completed in rs with a limited png plugin.

[quote]
Having all the events cluttered the RB way and wondering which one has code in it is kind of cumbersome.[/quote]

From my perspective the bold font events (with code) stick out like a dead tree in a forest so empty non bold events are visually ignored. I don’t really see any issues with clutter as I generally keep all the control events expanded and reach a control’s events by double clicking on the control in the window as opposed to scrolling through the window control list.

[quote]
If you have several controls that use the same set of events, simply duplicate the first one with all its really useful events.[/quote]

True, but then that means creating a group of controls with all events, but no code, outside the margins of the window which can be duplicated OR duplicating an existing control with code and perhaps having to then erase code from several events.

I only build desktop applications so could not this be added in as a feature that would still allow one to delete unused events. Deleting unused events from the code during the final build as a general cleanup of the project is a one time thing, but having to add events repeatedly sort of wastes time.

[quote=145146:@art ouette]If you have several controls that use the same set of events, simply duplicate the first one with all its really useful events.
True, but then that means creating a group of controls with all events, but no code, outside the margins of the window which can be duplicated OR duplicating an existing control with code and perhaps having to then erase code from several events.

I only build desktop applications so could not this be added in as a feature that would still allow one to delete unused events. Deleting unused events from the code during the final build as a general cleanup of the project is a one time thing, but having to add events repeatedly sort of wastes time.[/quote]

You do not get it. Create a control with all the events you may need or want, and when you have your porcupine complete, duplicate it. RB did not add anything in the new events either. Although you could duplicate controls with already coded events if you wanted, and that is possible with Xojo as well. Sure, you will have to strip out unused events eventually, but you do get your full collection to start with, and as you said, you do not sort of waste time adding each event.

I do not believe it is a valid way of proceeding, though. Unless extraordinary circumstances, most of the time if you need half a dozen events that’s already a crowd, and most frequently 2 or 3 is the norm. So having a full compliment of events which, as explained Greg, all chip some computing cycles, seems not very rational.

I do agree it takes a bit of time to add events in Xojo, though, since one has to use the mouse, and if it was possible with the keyboard, it would be faster.

This is an example of a good occasion to embrace the new. Xojo is certainly not a new version of RS. It is a new environment, with it’s own way of doing things. Pretty much like shifting gears with an automatic car makes no sense…

A simple solution would be to allow multiple selections when adding a new event.

i think you can add multiple event all at once.

That already works.

Oh - never realised that. I presumed from the OP that he had to add each one separately!

Indeed, that is a great idea. Pressing Cmd-A does select all events at once. And one can add only those needed, for a cleaner code.

Actually I do think I do get it.

  1. Drag various controls into the project, but outside the borders of the window to act as a temporary group of controls that can be readily duplicated with events already added manually. In my case I’d add all the events to each control as I really don’t want to even think about adding this or that event later - I want it to already to be there is case I want to use it later while working on the project since I never really know what events I may need say 3 months from now.

During the final build I quickly scroll down the list of controls and remove all the unwanted events as part of the final project cleanup. I also remove the temporary set of controls used for duplication.

OR

  1. Duplicate an existing control from the project window which has already has code and delete the code, quite possibly from several events for that control.

OR

  1. Drag a control onto the project and manually enter events each time.

Ideally though, I shouldn’t really have to bother with any of that - i should be able to drag a control on to the window and it already has all the events which I can always delete later as part of the final cleanup of the project which I only have to do once.

So why can’t a preference be added to automatically add all the events to a control dragged onto the project, but still retain the ability to manually delete those events later - the best of both worlds? Those that don’t want to use it will not have their use of Xojo compromised. What exactly is the big deal - is it not technically possible or would it involve too much company resources?

Yes, that works - it was one on the first things i tried, along with the other methods above, when I saw there was no longer any events automatically added, but I don’t view it as a solution as I don’t want to manually add events at all - I want to drag and drop and go to work.

i can’t even remember when is the last time i drag a control manually from the library and put in the events manually. Most of the time we just copy an existing control (e.g. a Date field or Amount field) and paste to a new one with all the codes all ready for use.

Yes, you do.

It is an old discussion.

I prefer the old way with a separate project tab for organisation, as it was more beginner friendly in showing you the available events and allowed you to hide unused events.

On the other hand the new way forces you to think more about which events you really want to use, and organisation can be improved by using folders (LOTS of folders). Plus there are lots of benefits to the newer versions like less bugs, better debugging, more features.

It is different but works too. What you prefer is up to you, the direction it develops in is up to Xojo.

I just wish people wouldn’t try to cram their preference down other people’s throat.

After all, we do get it.

Without looking, I’m guessing there’s already a feature request filed for this. I don’t see how it would hurt to have it as a user selectable option. Of course, it’s going to be fairly low on the priority list I imagine.