kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 4/18/2017 5:01 AM, Oliver Walters wrote:
> Wayne,
> 
> With this in mind, I am unsure how to determine (given a list of
> components) which sheet they originate in.

All of this information is in the SCH_REFERENCE object.  You will have
to cross reference the SCH_SHEET_PATH to find the appropriate
SCH_SCREEN for each object.  SCH_SCREEN (derived from BASE_SCREEN) is
where the undo/redo stacks reside.

> 
> I need a SCH_EDIT_FRAME* for each component, to work out where to push
> each undo operation. 

You shouldn't need the SCH_EDIT_FRAME to find the undo/redo stack
objects if you have the SCH_REFERENCE objects.  See above.

> 
> I have a list of SCH_REFERENCE objects, is there a way of determining
> where each object originates? Could you point me in the right direction? 
> 
> Regards,
> Oliver
> 
> On Tue, Apr 18, 2017 at 6:30 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     On 4/17/2017 4:18 PM, Oliver Walters wrote:
>     > So how do we proceed here? Is there a 'global' undo stack? If not:
> 
>     Unfortunately there is no global undo stack.  Undo stacks are maintained
>     for each unique SCH_SCREEN (schematic file) object.
> 
>     >
>     > A) don't allow changes made in the component table viewer to be undone
>     > B) Make an undo entry for each sheet that has changed symbols
>     >
>     > A) is easier but the user would need to quit-without-save to undo changes
> 
>     This is less than desirable
> 
>     >
>     > B) is more difficult and doesn't solve the undo operations getting out
>     > of order either, as the user could inject another operation on a given
>     > sheet.
> 
>     This would be my preference.  Out of order operations are already an
>     issue so this solution doesn't make that issue any worse.  Undo/redo is
>     only available for the current sheet so the user would have to change
>     sheets in order to undo anything changed in the component properties
>     table.
> 
>     >
>     > Suggestions?
>     >
>     > On 18 Apr 2017 01:26, "Wayne Stambaugh" <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>     > <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>> wrote:
>     >
>     >     On 4/17/2017 10:21 AM, jp charras wrote:
>     >     > Le 17/04/2017 à 04:11, Oliver Walters a écrit :
>     >     >> JP, others,
>     >     >>
>     >     >> After further investigation, I have worked out why the components
>     >     with duplicated references were
>     >     >> displaying incorrectly.
>     >     >>
>     >     >> Patch_004 is attached, Thomas can you confirm that it fixes the
>     >     display for you?
>     >     >>
>     >     >> Kind Regards,
>     >     >> Oliver
>     >     >>
>     >     >> On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters
>     >     <oliver.henry.walters@xxxxxxxxx
>     <mailto:oliver.henry.walters@xxxxxxxxx>
>     <mailto:oliver.henry.walters@xxxxxxxxx
>     <mailto:oliver.henry.walters@xxxxxxxxx>>
>     >     >
>     >     > Good work, Oliver!
>     >     >
>     >     > I found 2 issues (tested on W7)
>     >     >
>     >     > 1 - m_reloadTableButton is not correctly enabled/disabled.
>     >     > This is due to the way events are managed, and this is OS
>     dependent.
>     >     > To avoid this issue, enable/disable it inside a wxUpdateUIEvent
>     >     attached to this button.
>     >     >
>     >     > 2 - ESC key and ENTER keys do not dismiss the dialog.
>     >     > This is due to the fact you do not have a
>     wxStdDialogButtonSizer,
>     >     and no OK and Cancel button.
>     >     > Please, add it and use the OK button (as usual in a dialog) to
>     >     transfer changes to schematic (do not
>     >     > use a wxCloseEvent to manage that), and obviously Cancel just
>     >     closes the dialog.
>     >     > To do this transfer, just  override
>     TransferDataFromWindow(), that
>     >     is called by wxWidgets when
>     >     > closing a dialog by the OK button.
>     >     >
>     >     > About other things, undo/redo lists should manage only changes
>     >     made inside the corresponding sheet,
>     >     > not in other sheets, to avoid inconsistencies and therefore
>     crashes.
>     >     >
>     >
>     >     This is one of the reasons I've been reluctant to accept code that
>     >     attempts to change the state of a SCH_SCREEN object other than the
>     >     current SCH_SCREEN object.  It exposes a known flaw in our
>     schematic
>     >     undo/redo design and I have yet to see anyone update the undo/redo
>     >     SCH_SCREEN stacks correctly.  I see the potential for serious
>     issues if
>     >     you do not keep the undo/redo stacks properly synced.  Once
>     you allow
>     >     the modification of information in the SCH_SCREEN object other
>     than the
>     >     current one, you need to update the undo/redo stack for the
>     appropriate
>     >     SCH_SCREEN object.  Otherwise, you wont be able to undo all of the
>     >     changes correctly.
>     >
>     >     _______________________________________________
>     >     Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     >     <https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>>
>     >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >     Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     >     <https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>>
>     >     More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
>     >     <https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>>
>     >
> 
>