With the “Analyse project” command, there are the “Unused event parameters” and “Unused method parameters” sections, which are often full of unwanted warnings.
For the “Unused method parameters” section, I understand someone may have defined a method, thinking a given parameter would be mandatory, only to discover in the end that this parameter is actually unused (consequently, removing the parameter off the method signature).
But events are defined from the framework*, so it’s useless to tell one hasn’t used a parameter: we can’t remove it from the signature and we’ll certainly not use it dumbly (e.g. x=x) just to hide the warning.
Granted, warning sections can be hidden as choices, but if the entire section isn’t useful by definition, why does it exist in the first place?
There are “user-defined” events, right. Those are so rare in comparison to framework-used ones that even if it’d be interesting to know if a custom event should be redefined to have less parameters, it’ll always be hidden between a lot of framework events anyway, because almost no one will use all the parameters of all the used events.
I’d suggest having a section for user-defined events and remove the one for framework ones, but I’m thinking I’m overlooking something…
For my own cases, it’ll work (a lot of pasting in every involved event, though).
But my question was more general: since one won’t be able to change the event’s signature nor forcibly use all the parameters, is it worth having this kind of warning?
I believe it is. Sometimes I change an event definition between versions and may not remember that I can now access more useful information than I could previously. Same with my customers who use my components. This warning lets me know that I’m forgetting something.
As I said, I’m not talking about event definitions (user-defined ones) but only framework events (MouseDown, Paint, etc.).
For user-defined ones, I totally get the point. You may even have forgotten you added a parameter for “nothing” in the first place.
That’s why I’m thinking these warnings should only be about event definitions added by the user, not the framework’s ones.
But I still guess I’m under-considering something…
This also applies there. If Xojo changes an Event Definition (which they do from time-to-time), I want to know. I want to know what changed and how I can leverage it in my project.
Makes sense, but then the “#pragma Unused VariableName” will hide these changes as well.
So if you want to know about these changes, you have to keep them listed as warnings.
Are you never annoyed when you need to search for a custom event warning inside a long list, or when you get 500 warnings about unused parameters you don’t hide juste because they may change in a future release?
Wondering if this could be made better, that’s all.
If you use #pragma Unused, you don’t get the warnings anymore for the parameter you specified in the pragma line, so you can search however you like. I try to add these pragma directives as I code, so I don’t have to go back when performing an analysis.
My mistake; I read too quick. “VariableName” in the code you gave is obviously a specific variable name and not “all variables”…
So yes, your next answer is also covered by this.
Hide the parameters, one per line, and you’re fine.
Still wish Xojo could provide a command to “Add pragmas for all unused parameters”, which would, once executed, find all the unused event parameters and add “#pragma unused x” at the top of the event.
So you could, with just a click, hide these warnings and have a “snapshot” of what you currently have ignored.
Until now, I always ignored these warnings and not used this particular pragma. The downside is that I was “upset” by them and used “Analyse project” as rarely as possible (preferring to try-to-run and see errors only).
This pragma is really simple, once you get it correctly.
You can already select which analysis warnings you want to see by going to Project > Analysis Warnings in the menubar. I doubt they’d add a differentiation, but please do open a Feature Request if it’s something you want.
Differentiating between framework event parameters and custom event parameters is not worth, in my opinion, given what already exists (and which you pointed out).
The FR I’d consider is the one I quoted from myself (about a command to add the pragmas to all used events’s unused parameters in one move).
You can already sort of do this, but it’s on a per-method/event basis. Open an event definition, right-click the code editor, and select “Insert Pragma Unused for All Parameters”.
Most of the time, I’m also opposed to an IDE changing code automatically.
In this case, it’s about adding two unoffending lines, so this couldn’t break anything.
Years ago, I made a feature request to automatically adding “Return true” when creating menu handlers; this is now implemented. Do you think it wasn’t a useful request?
All these commands we see every day that fades out in mind… You start by never using them, then accustoming to “seeing” them and, when you need them, forget you had see them a long time ago… Thanks for pointing this.
I can see a benefit of a command for applying this to every event at once, though (which you’d not use if you don’t want).
I generally don’t add the #Pragma unused... until after the method or event handler is done and tested since I want to see those “Unused” warnings. Once I’m satisfied that the code is done, I’ll add then in from the ContextMenu item. I just wish it was smart enough to add the #Pragma unused... for just the actually unused parameters rather than for all of them.
