workbench initialisation - what exactly is meant to happen?

[mlampert]

Path uses InitGui for all UI related classes to register their commands and tools - so I used that same mechanism to register each operation's property in a registry (PathSetupSheet._RegisteredOps via PathOpGui.SetupOperation - in case you're interested).

And this works fine - unless the user never activates the "Path" workbench - yet still opens a document with a Path.Job in it and edits it.

If you actually do that _RegisteredOps is still empty, no operations have been registered - in fact none of them went through their basic initialisation code because all those are tied to somebody (something) actually importing the them.

So the real question is: how does one properly initialise all the pieces that make up a Workbench - even though the actual workbench is never loaded/activated by the user.

In case this doesn't make sense:
* create a Path.Job for your favourite solid
* set your default workbench to be "Start"
* shutdown FC
* startup FC and load above document with the Path.Job in it
* double click on the Job in the document (without having activated the Path workbench beforehand)

using above process you'll get a Transform dialog, and if you check the console you'll see an exception - which is a consequence of the Path infrastructure not being initialised correctly.

[easyw-fc]

If you post the error log, it would be easier to debug it.

[mlampert]

If you post the error log, it would be easier to debug it.

This is not a question of debugging. The question is how does one properly initialise a components of a workbench, when the workbench itself is never activated?

[easyw-fc]

It depends on what you are calling from the workbench and in which way the WB has coded its functions.
So, yes, this is a debugging question.

[wmayer]

In case this doesn't make sense:
* create a Path.Job for your favourite solid
* set your default workbench to be "Start"
* shutdown FC
* startup FC and load above document with the Path.Job in it
* double click on the Job in the document (without having activated the Path workbench beforehand)

using above process you'll get a Transform dialog, and if you check the console you'll see an exception - which is a consequence of the Path infrastructure not being initialised correctly.

This is a funny behaviour. But there is also something wrong how the PathJob implements the context menu and double-click. Independent if the Path wb was loaded beforehand or not the context menu always shows "Transform" in bold which is supposed the be the standard command that should be started by double-click.

Then when double-clicking without having the Path bw loaded beforehand it does two things (at least here). It opens the transform tool but also opens the correct dialog in the task panel. So, it at least does partially the right thing.
I wonder whether there is a way to force to initialize the Path wb if not yet done when editing a Path object.

[mlampert]

This is a funny behaviour. But there is also something wrong how the PathJob implements the context menu and double-click. Independent if the Path wb was loaded beforehand or not the context menu always shows "Transform" in bold which is supposed the be the standard command that should be started by double-click.

Then when double-clicking without having the Path bw loaded beforehand it does two things (at least here). It opens the transform tool but also opens the correct dialog in the task panel. So, it at least does partially the right thing.
I wonder whether there is a way to force to initialize the Path wb if not yet done when editing a Path object.

I did not notice the bold of "Transform", I'll look into that.
The "partially correct behaviour" is because the TaskPanel throws an exception during its creation as a result of the components not being initialised.

[mlampert]

I wonder whether there is a way to force to initialize the Path wb if not yet done when editing a Path object.

This is probably where I have to go - I was wondering if I made a conceptual mistake with the workbench initialisation and if that was the case I would've preferred correcting that rather than introducing an initialisation tracking.

There is a slight recursive dependency problem but I can probably work around that.