Returning unused objects from a project

I am modifying a project created with REALbasic in 2012 (the year) and updated to Xojo 2015r1.

I know about some unused objects using
image

in the IDE.

But what about some other object(s) like unused windows or… (Methods / Functions / Constants; whatever) ?

Actual unused stuff from that project:
image

A quick trick is to rename windows or classes by prefixing with a z and recompiling.
If there are no errors, they can be deleted.
(be careful if you have any #if TargetWin32 or #if targetMacos in your app… anything inside those may not be seen)

Keep in mind that the compiler strips a lot of things when they’re not used.

Yes Jeff, you are right, but with many items in the Navigation pane (and bad eyes as I have today…)

Greg:
My problem comes because I have to change images (of the user company) and was fooled by two windows with similar contents; one with the new logo (in the IDE) and the second (where ?) that have the old logo and this is the one that is displayed.

It was certainly a detritus (the old window vs the new window with a different interface).

Too many things to do, so few time to achieve and too many images to change…

I started (again) to work on that project, but far more slowly, and it start to work.

Removing now useless prototyped objects (window in this case) allow to not modify the wrong window ! :grinning:

NB: that project was not built as a multi-company usage (images are company specific, and everywhere. Nice, but boring when a need for a change happened).
I now understand why my other two applications for the same clients were build with an easy to change application name/logo (I placed data in a special folder and the application display what was there). It was not the case with this application that I wrote some years earlier.

These you can remove as warnings by adding #pragma statements to the items in question.

For example unused event parameters. The Paint event sends an array of rects which need to be redrawn, if you don’t use that parameter then it will show as a warning. You can prevent this by adding

#Pragma Unused areas

to your paint event. That way you are acknowledging that you don’t need to know that it is not used.

As for local variables and method, if they are your own invention then you have to consider if they are needed any more. If you can delete the definition of one and the code still compiles then very likely they’re not required. With method parameters you would beed to adjust all the calls for the methods become you will get a clean compile.

If the methods are not yours you can still use the pragma statement to prevent the warning.

Nice explanation. You may enhance it and report the result in the Code Sharing channel. This is good information for the average Xojo developer.