ActiveGuiDoc

[jrheinlaender]

Hello Jürgen,

can you explain a bit more about how this is supposed to work? Currently ActiveGuiDoc is set by PartDesignGui::setActivePart when the user double-clicks on a body.

But this is very annoying if I work with multiple documents in different tabs. Every time I change to another Part, I have to double-click again on the body I want to work on.

What about introducing a Body::IsActive property instead? This would have the added advantage that the active body is remembered through a save/load cycle.

Jan

[jriegel]

Hi Jan,
I'm not quite sure I understand your problem!? Setting the active part object is at the moment done by double click the Body, but I can think of lots of ways to make it more convenient then that. E.g. when selecting a face and create a sketch on it, the command can check if that face is in the active Body or an other Body. Then you can make the other Body active. Saving the active Body makes IMO no sense, since you never know what the user wants to do after load, or even if it use the PartDesign workbench. Also it makes no sense as a property of Body, since you can have different Documents whith active Bodies loaded, or a lot other problems. Saving to much state with a document is generally problematic.
I think the better way is to make the PartDesign commands more sensitive toward determine what Body the user wants to work on and do the switching. Double click was only the first way to do it.

Im not quite sure what you mean with "ActiveGuiDocument"?
There is the general mechanism of the ActiveObject, which is used e.g. in python "App.AcctiveDocumen.ActiveObject...." to access the latest created object. That mechanism is mainly for macro recording, where is generally bad to include hard names. There the activeObject() is a convinient way to issue the latest added object without using its name, to set parameters.

Or do you mean the static variable in PartDesignGui? That one is only a cache to get fast access to the gui document of the ActivePart object...

[jrheinlaender]

My specific problem is that I have two parts open in two different tabs (or windows). When I switch between windows, how would the PartDesignGui be notified so that it can set the static variable ActivePartObject to the correct body?

[wmayer]

Have a look at src/App/Application:

Code: Select all

boost::signal<void (const Document&)> signalActiveDocument;

[jriegel]

Now I think I understand... You think of heaving different contexts per document, with active Part for each document opened. Thats basically right, every multi-document software does that in some respect. E.g. M$ Word has a cursor position for each open document independently.

But that kind of context switch, which would normally include selection also, is not implemented in the base system so far. But as Werner showed you, how you can mimic it with receiving the signal for document change and then change the Active Body. You can keep a list of the last Active Part per document and activate it then. But I would not save that in any kind. Such a behavior could be located in the PartDesign Workbench class.

[jrheinlaender]

But I would not save that in any kind.

Although Text Processors do save the currently viewed page and cursor position with the document, so users might expect that from FC, too.

[jriegel]

You basically right, and if you want feel free to add a property to Body which indicate if its the last active one...

I personally want to develop more toward a project management:
https://sourceforge.net/apps/mediawiki/ ... management

The classic multi document approach not really work in a decent sized CAD project. There you have so many linking and dependencies throughout the parts. There fore after establishing the Assembly-basics I would go straight to a project management which handle design projects with lot of document (loaded or not loaded) under one tree and one 3D view. I think more towards as I know it works in my company and how software development works. Lot of files, and you load only the ones you actually working on. But the rest is managed under a project to keep track on revision control and change management. In this case you have only one 3D view and the document (loaded or not) are visualized and editable in that realm.