Bug? IntelliSense for hand-coded event handlers is unhelpful

[ShepSoft]

If you create an EditText view and write the event handler/s by hand they will fail if you get the signature/s wrong of course. However, the Intellisense will show your incorrect signature and not the correct one which renders it unusable as a debugging assistant. This is somewhere between a very minor bug and a low priority wish I suppose !

 

[Erel]

However, the Intellisense will show your incorrect signature and not the correct one which renders it unusable as a debugging assistant.

More information please. The IDE shows the correct event signatures.

 

[ShepSoft]

If you write the event handler by hand, incorrectly as shown in this image,
then the IDE assumes it's just any old Sub and shows the Intellisense for what you have written:

Thus, quite reasonably, there is no warning that you have got anything wrong.
When the Enter key is pressed at runtime however an error results:

Which means that the compiler IS seeing this as an event handler for the EditText.
Surely if the IDE does not see it as an event handler then the compiler shouldn't either and should not compile it as such ?

 

[Erel]

Which means that the compiler IS seeing this as an event handler for the EditText.

Event subs are not special. The compiler doesn't treat those subs differently. The only special handling related to event subs, is that subs names with an underscore will not be obfuscated.

Tip: Write Sub + space + tab and let the IDE autocomplete the sub signature.

 

[ShepSoft]

Your tip is extremely helpful and is obviously the way to do this. Thank you.

(If I wanted to write a Sub called ETname_EnterPressed which was NOT meant to be an event handler I couldn't -
where and how then does your build system hook the handler to the control?)

 

[agraham]

If I wanted to write a Sub called ETname_EnterPressed which was NOT meant to be an event handler I couldn't

If I understand you correctly your assumption is wrong, you can! An event Sub is called at run time by a dynamic check that a Sub exists whose name starts with the event prefix of the object raising the event and ends with the name of the event being raised. The mechanism is identical to CallSub. The existence of a Sub that looks like an event causes no problems. It will never be called as an event but can be called normally - as indeed can any true event Sub if you wish to do so,

 

[ShepSoft]

The existence of a Sub that looks like an event causes no problems

Why then do I get the runtime error illustrated in my earlier post ?

 

[Peter Simpson]

I highly recommend that you watch this video, auto complete event subs are at around 4.20.

I highly recommend that you start with watching this video, them slowly work your way through the other videos in the list.

I personally prefer to watch them on the Anywhere Software YouTube channel. It's a shame that Anywhere Software didn't add a subject time reference table in the description on YouTube, it makes referencing subjects easier to find.

 

[agraham]

Why then do I get the runtime error illustrated in my earlier post ?

Because you have an object called ETName that raises the event named EnterPressed and you have a Sub named ETName_EnterPressed whose parameter list does not match that expected when called.

I may have misunderstood you but I meant that you can have subs called ETName_NoSuchEvent or NoSuchView_EnterPressed and they will cause no problem and can be used as normal Subs.

 

[ShepSoft]

Thank you for your pointer to the video Peter about the great Sub helper feature, which Erel had pointed out to me earlier.

However, although it really is a rather minor thing, the IDE doesn't flag up an event handler with the wrong signature which can lead to runtime errors.
If I behave myself and let the designer do it - or use the Sub helper system - then there will never be a problem.
Thanks for all the helpful responses.