Loaded event handler choice is presented

When I create a WPF application and go to the window constructor and try to add a Loaded event handler, it used to get created as a choice in the popup at least when hitting Ctrl-SpaceBar. Now it doesn’t. Is that an oversight or bug?

Here is sample code:

   constructor Window1;
      begin
      InitializeComponent();
      Loaded += ;
      end;

It used to be that there would be a choice in the popup to create a method to handle the loaded event, like Window1_Loaded or something. And then when you chose that, it would generate the code with the proper arguments, etc.

In the past, there was a sort of maybe related problem while in Silverlight. Loaded default event handler doesn’t compile except in that the generated code wouldn’t compile.

hrmm I do see the item:

and

afbeelding

that said it seems to insert it wrong so I’ll log a bug.

Thanks, logged as bugs://81468

Ok, I thought it used to, by default, make the routine be called like Window1_Loaded and that is what I was looking for. Perhaps that has changed. Or maybe that is just the way it worked in Silverlight.

Thanks for checking it out. When I tried the OnLoaded one, it didn’t work for me either. It created a method OnLoaded, but it wasn’t a method of the object class. In the interface section, it added a method ok, but the implementation section did have the class name. Just “method OnLoaded” etc. instead of “method Window1.OnLoaded”. When I told the class in the interface section to complete the class, it created the method properly. But then the OnLoaded that wasn’t part of the class was still there.

Hope that helps you while you are looking at that bit of code. (and I hope I was clear enough)

Yes. I logged the but because it didn’t properly create the method and could name it better.

I’m not sure there is anything wrong with the OnLoaded. I just expected the old way. The old way was actually a little redundant. If the class is Window1, do we really need a Window1.Window1_Loaded? I’m not at all sure. I haven’t thought about such things for months. Maybe there could be some other object that also has a “Loaded” event. And in the class, if one is “OnLoaded”, then the new object’s method couldn’t be “OnLoaded” also. That is probably why the class was getting prefixed. That way you could have a bunch of different classes used by the Window class that each have their own Loaded event handler and there wouldn’t be as likely a name collision.

Just my rambling thoughts.

bugs://81468 got closed with status fixed.

I’m looking back at creating an Oxygene project again (after retiring and being retired for a while :slight_smile: ).

I don’t think this works right still. Or at least it doesn’t work nearly as well as it used to.

I’m using version 10.0.0.2525.

While working on a WPF application and I’m in a procedure named “TestProcedure” and if I type, “Loaded +=”, I’m pretty sure it used to pop up a dialog that had “TestProcedure_Loaded” as the suggested name. Then if I selected that, it created the “Loaded += TestProcedure_Loaded” and created the “method TestProcedure_Loaded” in the object class definition and created a matching stub implementing the procedure whose body was just “begin end;”.

If I then wanted to add a loaded event handler to another method named “Test2Procedure”, it would have “Test2Procedure_Loaded” as the name choice and create the new, differently named interface and implementation code.

But none of that stuff works anymore and it was a great time saver. Now, the MOST it does is that if I select the OnLoaded choice from the popup, then it created the implementation code, but didn’t also create the matching interface section in the class.

If I go ahead and create the matching interface using “Ctrl-Shift-C” and then want to create another event handler in another method, the choice of OnLoaded is presented again and if chosen, it creates another OnLoaded implementation code stub with the same name as the first one.

So I don’t think the bug has been fixed. Or at the very least, it is a nuisance to used compared to how nicely it used to work which saved a lot of time fixing things manually.

This used to be so valuable, I’m surprised it was dropped and that other people haven’t complained. I presume other people just manually coded it themselves in a multi-step process.

Maybe other people have just switched to using the “method” mechanism that generates unnamed inline handlers (which I think makes code less readable).

If this isn’t clear, I can try to take some snapshots of what I’m saying and post those too.

(fwiw, probably “Loaded” isn’t the best event to use as an example, but imagine any other event that might want to be hooked into and unhooked in various procedures in which case there would be the need for a bunch of methods all trying to share the same name for the event handlers)

Hmm, pretty sure it’s still doing that. Is this in Water or Visual Studio? does this repro with a fresh project from template?

Sorry for taking so long to get back to you. I had a hard disk die, got a new high powered machine because the other one was getting “old”. So just got stuff put back here. Then I replaced old machine HDD with an SSD and now that one works great again. “Upgraded” my wife’s machine to that old one.

So…

Yes, it doesn’t seem to work like it used to in either latest production Water or Visual Studio Pro 2017.

So what exactly is wrong on this screenshot?

There is no “Window1_Loaded” event as a choice in the popup. I’m pretty sure it used to be the first one there and then the rest in alphabetical order or something. And now, it isn’t ANYWHERE. There is a Loaded in the list, but my recollection is that when you selected the handler, it created the stub interface in the class definition and an empty stub method implementation. Now when I selected Loaded, nothing happens.

I particularly liked the automatic generation of the stubs because it had the necessary arguments all there and with the proper types so I didn’t have to look it up and do all that manually.

Was that whole mechanism dropped somewhere along the way? Or is it supposed to still do that and doesn’t?

As I mentioned earlier, the OnLoaded event handler is there as a choice, and THAT does create the method implementation stub, but doesn’t create anything, private or public, in the interface section.

Also, if I wanted another method to temporarily hook to the same event, if I add another Loaded += OnLoaded, it creates ANOTHER method with the exact same event handler name “OnLoaded”. I think that is why it used to create different names for the handler. So if my method that I wanted to hook the event was called “MyMethod”, I thought it used to create something like “MyMethod_Loaded”.

There is also a method… choice, but that creates a little inline method. But I want a proper method in the class like it used to do.

Of course, it has been a long time since I’ve done these things and maybe recommendations and the way to do this has changed. Or maybe it only did it in Silverlight which was primarily what I coded. And now I don’t even think I can create a Silverlight app to test how that used to work. (Thanks Microsoft! not)

p.s.
The title of this question was supposed to be “Loaded event handler choice is NOT present”, but I don’t know how to change it. Hopefully it was clear the rest of my comments.

Also, I asked about this same sort of thing way back in 2014 which I think is when I switched from the Borland Prism to RemObjects. I see Carlo was going to look into it back then. I think he must have fixed it after that because I seem to recall using that a lot in Silverlight with RemObject’s Oxygene.

The previous, first time I asked about this sort of stuff was in:
https://talk.remobjects.com/t/how-do-i-make-the-event-handler-method-auto-generate-the-code/3746

I just tried creating an event handler in Microsoft C#. THEY are generating the method the way I would expect Oxygene to do. At least they are in the constructor.

Thanks, logged as bugs://84779

Thanks

Any progress on this bug?

My apologies for the delay. The VS team has been swamped with a few really tricky and longwinded issues these ist few weeks. So things are a bit behind schedule. I’ll make sure this issue gets priority next week.

Thanx for understanding.

No worries.

1 Like

bugs://84779 got closed with status fixed.

bugs://E24447 was closed as fixed.