Explorer redraw after system/directrun plugin execution

Posts   
 
    
Posts: 39
Joined: 19-Dec-2022
# Posted on: 14-Jun-2023 17:19:54   

Hi, I've written a plugin which iterates over all entities + most of the db objects and does some work on them. This plugin should automatically subscribe to the event "SyncRelationalModelDataAfterFinish". For this to work it looks like the plugin needs to be of the types "System" or "DirectRun". Since many elements in the project explorer and the catalog explorer are touched I want also to set "SuppressProjectExplorerRedraw" and "SuppressCatalogExplorerRedraw" to true, otherwise the plugin is horribly slow.

However, with those settings I seem to have one problem: after the plugin is run there is no redraw for the project explorer and the catalog explorer and both are empty. I have to reload the project to again see something there. It seems that only for plugins of type "SingleAndMultiElementPlugin" a redraw is done, but for those auto event subscribing does not work.

Is there a reason for this strange behavior (happens in 5.8, 5.9 and 5.10)?

Is there a way to have a plugin with auto event subscribing, suppressed redraw during execution, but redraw after execution?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39760
Joined: 17-Aug-2003
# Posted on: 15-Jun-2023 10:03:32   

I see the setting SuppressProjectExplorerRedraw is indeed used when the plugin is ran manually, but when the plugin is running silently (which yours is) then it's switched off but not switched on again. Clearly a bug, which should be easy to fix.

However we have to check if this runs into other problems, or there's a reason it's not redrawn at that point.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39760
Joined: 17-Aug-2003
# Posted on: 15-Jun-2023 10:24:00   

Analyzing the flow, the following happens: - all plugin runs are done with the same function, which always switches off the catalog/project explorer when the flags you're using are set. - if the plugin was started from the UI, it'll set a flag that the plugin has ran. If the plugin was started unattended, it doesn't, because in theory it doesn't know when it ends; the plugin might start threads which run for a long time. - if the plugin was started from the UI, it'll switch on the project/catalog explorer again if they were switched off and the plugin has run properly.

As the flag is never set, the project/catalog explorers aren't switched back on; it doesn't know when to do that.

So the 'easy' fix to set the flag isn't that simple, as it might very well be premature to set it (and switch the catalog/project explorers back on) as the plugin might still be busy.

We'll look into whether there's another way to do this.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39760
Joined: 17-Aug-2003
# Posted on: 15-Jun-2023 11:10:19   

We came to the conclusion that if a plugin spawns several worker threads, it still has to wait till they're finished before returning, and in the current situation it won't get the explorers back anyway, so we switched on the flag after the plugin execution call returns. This is available in hotfix builds 5.9.6 and 5.10.2 which are now available. We tested this with a test plugin which is bound to the same event you bind the plugin to, switches off the explorers, waits two seconds and then returns and the explorers come back after we have synced the relational model data.

Frans Bouma | Lead developer LLBLGen Pro
Posts: 39
Joined: 19-Dec-2022
# Posted on: 16-Jun-2023 18:12:02   

Very good. Thank you very much! I just tested it and it works as expected. Both explorers are redrawn after execution.