I have written a SKILL procedure that allows for forward/backward browsing of Edit-In-Place cells, to allow layout users to jump from the current instance of the current EIP cell to another instance of the same cell. I have written it to support mosaics and figGroups, and it works well enough as far as I can tell.
However, during the course of testing, I encountered a strange and unexpected behaviour, which fortunately I can reproduce very easily on the CIW without even loading my script.
To reproduce this behaviour, the following steps can be carried out:
1. Create a cell, let's say cellB (just throw in a shape or two so it's not an empty cell)
2. Create another cell, let's say cellA
3. Create two instances of cellB in cellA, and create a new figGroup that contains these two instances
4. Create another cell to serve as the top cell
5. Create an instance of cellA and an instance of cellB in the top cell
6. Select the cellB instance and then in the CIW, assign a variable to it by:
(setq testinst (car (geGetSelSet)))
7. Then manually perform Edit-In-Place three times on cellA:
i) Select cellA, then press X (to perform EIP)
ii) Select the figGroup, then press X
iii) Select one of the two instances of cellB, pressX
8. The layout window title bar should now show "your_lib_name cellB layout". Now, execute the following command in the CIW to return to the top cell and supposedly exit EIP status:
9. Lastly, perform EIP in the CIW with the following command:
(leEditInPlace (hiGetCurrentWindow) (list (list testinst 0 0 0)))
At the end of this, I find that the layout title bar now shows "lib_name cellB layout [group: Group0]", which indicates that Virtuoso has descended into a figGroup (with default name "Group0"), even though the testinst is not in a figGroup.
This can also be confirmed by executing "leGetEditFigGroup" in the CIW, which should return a figGroup object, and that figGroup object is the same figGroup object created in step 3 above.
So, my question is, is this behaviour expected and normal? To me, it seems to be a bug, as my "leEditInPlace" command executed on step 9 is on an instance that is not in any figGroups. It seems that Virtuoso did not refresh its figGroup edit status even though I have returned to the top cell with "leReturnToTop".
On top of that, this only happens when the figGroup hierarchical level is the same as the instance descended into by the "leEditInplace" command. If for example, another instance of cellA is created in the top cell, and the following command is executed:
(leEditInPlace (hiGetCurrentWindow) (list (list cellA_inst2 0 0 0) (list cellB_in_cellA_inst2 0 0 0)))
where cellA_inst2 is a variable assigned to the second cellA instance, and cellB_in_cellA_inst2 is a variable assigned to one of the cellB instances in the cellA_inst2 instance
This command if executed, will not produce the strange behaviour explained earlier, and "leGetEditFigGroup" will return nil here (which is actually correct), even though it is another instance of the same cell containing the same figGroup object.
I have searched the forum for answers or hints to solving this problem but have come nowhere close to it. Any help or insight would be appreciated.
I tried this out using IC618 ISR6 (the latest hotfix) and don't see this behaviour - it works fine and correctly for me. I then did a bit of searching and found what could be a relevant CCR (it's not precisely the same symptoms you describe that was reported with this, but I can imagine it might cause a similar issue, CCR 1890689). This was fixed in IC618 ISR2 (IC6.1.8-64b.500.2). As I'm travelling at the moment, I don't have so many versions easily available so I tried in IC617 ISR23 (which is before that version obviously) and I can see the problem you describe.
So, not sure which version you're using (this is why the forum guidelines ask you to provide such information - important alongside the very clear instructions that you've given on how to reproduce the problem), but it seems likely from what I've found that it was indeed fixed by virtue of this CCR in IC618/ICADVM181 ISR2.
Can you check in a more recent hotfix?
Thanks very much for your quick response! Sorry I forgot to mention the version I was using, which was IC617.500.1200.
I then tried IC618 ISR2, and the problem does indeed seem to have been fixed!