Deprecation and Removal (of a feature) are a ay of life in our industry.
At the light of the Graphics Removal questions, maybe something have to be done by Xojo.
Maybe, with a preference, adding a warning at compile time (and stop here: no compilation done unlike the developer change a Preference *) have to be done when the feature is deprecated (in advance of the Removal) ?
The text can display a warning string plus a hint on how the new way have to be done (or a reference to a PDF in the Read Me folder) or whatever mechanism Xojo will use to explain its developers what to do.
So, developer are really aware of what happens and change their code to comply with the new way(s).
And, if in a hurry to release the application, the developer can change the preference to be able to generate the code (until he have time to modify it)
Edit:
Better do something like that than letting application with deprecated stuff / and get a devopper asking people who forgot the new how to since they swapped to the new way years ago).
BTW: this is not a rant, just an advice/clue on how to improve the Xojo user experience, and to avoid future troubles.
And if that preference is on Project basic (hold the name of the project, flag the feature in new or old projects) .
I mean you can do the same yourself with just having an extra picture for the canvas.
instead of graphics, you use your picture.graphics. When you query graphics, you trigger invalidate, too.
Than in paint event, you draw the image.
In a 2013 application (started with Real Studio, still working on Xojo 2015r1), I had to enforce some data entries (remove the too error prone TextField to three PopupMenus).
I also had to TRIM some other entries.
Worst, after five and a half years, when I get an eye on the latest db file, I found many, many other writing errors in the DB.
Doh ! I forgot to add that I strongly dislike to make constraints in a software application. Butfor DB clarity safe, I add some.
The people who use that db (read / write) are white hair people, so it is not really easy. And I do not train them they are volunteers in a charity entity, so things are not easy in that case.
Just use “Analyze Project” to get a list of deprecation, unused variables, stuff like that. Unused Method and Event parameters are pretty noisy, but you can disable those if you like. There’s a lot of gold in the analyzer.
IDE » Code Editor There’s a new contextual menu available that will write a single #pragma unused line for each parameter to a method, event or computed property setter
[quote=413533:@Jason Parsley]See the release notes for 2018r3 re case #52735
IDE » Code Editor There’s a new contextual menu available that will write a single #pragma unused line for each parameter to a method, event or computed property setter[/quote]
nice feature !
just a thought
could it be smarter and after using the analyzer that finds unused parameters, to set only the unused ones ?
This should already be possible. If you analyze a project and select a bunch of rows and right click it will insert #pragma unused for whatever ones you select.
And after all: why not a Preference to do that automagically (or not) at “Analyze Project” ?
Not used variables: it is questionnable, but with a Preference they can be commented (letting the developer remove it or use it (after all if someone declare a variable (s)he certainly had a good reason in mind )