What can be done about it?
Does anyone have a clue there?
go to the cache folder and remove all 3.x caches ? (not only 3.0, 3.1 but also 3.2)
Did you check if target -> 32 or 64 bit makes a difference ?
We did that. Didn’t help.
It seems like the compiler has an issue, but doesn’t report it.
e.g. fails to load a plugin, but the code for autocomplete can load it.
Loading Xojo from the terminal and using it spits some error/warning/tip?
It may be a change in the sdk (internals) ?
This is not a new bug: <https://xojo.com/issue/45100>
It has been there for years.
This is an annoying one, but still the IDE becomes slow when having lot’s of plugins loaded. I do not see that being addressed by Xojo as well…
This is a closed bug report (so in xojo terms it doesn’t exist or isn’t provable). But it’s not a new one i know.
When I see this issue then it is usually caused by plugins that do not have full set of platforms in them.
And it is not always the plugin that shows the problem, but can be another earlier in the load.
(as dumb as that sounds then it seems to actually matter)
There is no MBS or Einhugur plugin without a Windows part.
Maybe @William_Yu can look into plugin loading code to make sure the IDE writes messages on DebugView whenever a plugin DLL fails to load.
FWIW, if the IDE autocompletes then the plugin loaded successfully. Maybe your class depends on another class that didn’t load successfully? I’m not sure exactly what the issue is but there is certainly a compilation error, with types, function prototypes, or something related. I agree we should do something better than nothing if the plugin didn’t load successfully.
As you see on screenshots above, the WIA class was seen by autocomplete.
But compiler doesn’t know it as identifier.
How can we debug?
Maybe some exception was raised in parser earlier and ignored?
I think the compiler knows it, but there’s a compilation error with it that it doesn’t report as nicely since it’s all generated plugin code stubs. Unfortunately we don’t log what the actual underlying compilation error is, but I suspect we have it so please file a request for us to report it somehow. However in your current predicament I would probably go through your WIA class that is having issues and start removing/adding stuff and see what the root cause is.
Please note that other day the same plugin works just fine.
There is nothing to change on the WIA plugin.
I’m not sure what that means, did it work in 2019r3 and not in 2020r1 anymore? Could a new class/type introduced in 2020r1 cause conflicts with some of your plugins? I could not download these WIA classes on your website to help you track this down.
This is not new. I have clients reporting those errors to me.
The last client had this trouble with 2019r3.
