View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000946 | FreeCAD | Bug | public | 2013-01-07 11:28 | 2013-02-25 21:38 |
Reporter | shoogen | Assigned To | yorik | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 0.12 | ||||
Fixed in Version | 0.14 | ||||
Summary | 0000946: Objects imported by Drag-n-Drop end up in the wrong document | ||||
Description | Using functions to create Draft objects uses the active Document. Though this might not be set to apropriate. | ||||
Additional Information | This happend at least for importCSG if the first element is a Draft.makeCircle | ||||
Tags | No tags attached. | ||||
FreeCAD Information | |||||
|
Can you be a bit more specific and describe in some steps how to produce this behaviour? At least it doesn't seem to be a general problem but only in some special modules. Here my workflow: * create two documents and in the tabbar select Restore to show the two windows in normal mode. * drag and drop a STEP file to the mdi window which has NOT the focus You can see it loads the file into the correct document, i.e. not the active one. |
|
Indeed the draft module creates objects always in the active document, but i can't really think of a case where it should be otherwise... as Werner says, we'd need a specific case. |
|
i created two empty documents. I downloaded http://www.thingiverse.com/download:115211 to a local directory. (On windows) i drop the scad file onto the first/inactive document in the combo (tree) view ('unnamed'). The first Draft.Circe is created in 'unnamed' the all further elements are created in 'unnamed' i got multiple errors: Gui::DocumentItem::slotChangedObject(): Cannot reparent unknown object. @Werner: I dn't think that having the focus in the GUI has anything to do with being the *App*.ActiveDocument @Yorik: This might has not been tested before because it not a problem if there is only one open document. A simple fix would be to call setActive before calling the Draft module. But i think this could also affect all importers in Draft and Arch as well. And therefore would have to be done in all importers that use functions that rely on App.ActiveDocument example: def insert(filename,docname): "called when freecad imports a file" global doc #global pathName groupname = os.path.splitext(os.path.basename(filename))[0] try: doc=FreeCAD.getDocument(docname) + FreeCAD.setActiveDocument(docname) except: doc=FreeCAD.newDocument(docname) + #FreeCAD.setActiveDocument(doc.Name) #alternative implementation ceterum censeo, there should be a method for this (doc.setActive()) like there should be obj.remove() for doc.removeObject(obj.Name) |
|
I must test a bit (i'm still without computer) but this looks like an easy solution indeed... other solution could be to allow to give a docname to all draft makeSomething functions, but it might be overkill... |
|
I doesn't work as expected. |
|
> @Werner: I dn't think that having the focus in the GUI has anything to do with being the *App*.ActiveDocument I was probably not clear enough but we both meant the same thing. It is not supposed to call the setActiveDocument() method from with the insert() function. This can have impacts and according to your last post it seems it really does. Would it make sense to copy the code from the Draft.make***() functions to the CSG importer and adjust it to your needs? |
|
In that case it is probably better to add an optional argument to the Draft make functions, that allow to pass the document. It's not much work, there are not so many. But the day you need other tools from other modules, this won't work... |
|
If I'm not supposed to setActiveDocument() from the insert() function then, i have to put up the question if it makes more sense to call it in in c++ space, before calling the python insert function. I do not fully understand the concept of the ActiveDocument yet. I see the usefullness at the python console. But i didn't get when it is updated. this problem occurs only under rare circumstances. And the workarounds in OpenSCAD module would be simple. But i think that this is a design flaw |
|
Committed the above fix in 8e3e4b2 I probably couldn't test every situation, if this is still an issue, reopen! |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-01-07 11:28 | shoogen | New Issue | |
2013-01-08 09:40 | wmayer | Note Added: 0002818 | |
2013-01-08 10:58 | yorik | Note Added: 0002823 | |
2013-01-08 11:03 | yorik | Status | new => assigned |
2013-01-08 11:03 | yorik | Assigned To | => yorik |
2013-01-08 11:44 | shoogen | Note Added: 0002825 | |
2013-01-08 11:51 | shoogen | Note Edited: 0002825 | |
2013-01-08 11:51 | shoogen | Note Edited: 0002825 | |
2013-01-08 11:54 | shoogen | Note Edited: 0002825 | |
2013-01-08 11:56 | shoogen | Note Edited: 0002825 | |
2013-01-08 11:59 | shoogen | Note Edited: 0002825 | |
2013-01-08 12:46 | yorik | Note Added: 0002827 | |
2013-01-08 17:08 | shoogen | Note Added: 0002828 | |
2013-01-08 18:35 | wmayer | Note Added: 0002830 | |
2013-01-08 19:44 | yorik | Note Added: 0002831 | |
2013-01-08 20:40 | shoogen | Note Added: 0002832 | |
2013-02-25 21:38 | yorik | Note Added: 0002942 | |
2013-02-25 21:38 | yorik | Status | assigned => closed |
2013-02-25 21:38 | yorik | Resolution | open => fixed |
2013-02-25 21:38 | yorik | Fixed in Version | => 0.14 |