kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

These are currently reasonably common in the code:

1)
m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) { 
					    this->PopupMenu( this->m_footprintContextMenu ); } );

2)
m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) { 
					        this->PopupMenu( this->m_footprintContextMenu ); 
                                            } );

3)
m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) 
                                            { 
					        this->PopupMenu( this->m_footprintContextMenu ); 
                                            } );

4)
m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) { 
    this->PopupMenu( this->m_footprintContextMenu ); 
} );


5)
m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) 
{ 
    this->PopupMenu( this->m_footprintContextMenu ); 
} );


6)
m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) 
    { 
        this->PopupMenu( this->m_footprintContextMenu ); 
    } );

Personally I’ve been using either (1) or (6), depending on length.  (I’ve gone back and forth between 5 and 6: do we want them to look different from a normal block, or not?)

I’ve got no strong feelings.  But I think we should pick one or two to “bless”….

Cheers,
Jeff.

> On 12 Jul 2019, at 12:31, Ian McInerney <Ian.S.McInerney@xxxxxxxx> wrote:
> 
> The higher SNR was one reason why I was thinking of switching the handlers over to them, since then we don't need the separate function declaration/function body, and it also makes it clearer what the actions do. For instance this is one that I have added during my work on cvpcb for the context menu:
> 
> m_footprintListBox->Bind( wxEVT_RIGHT_DOWN,
>             [this]( wxMouseEvent& ) { this->PopupMenu( this->m_footprintContextMenu ); } );
> 
> I personally find that easier to parse than the event-table form since everything is in one place. Looking through the current code base, the layer widget is the only other window to make use of the lambdas inside bind, so I figured some guidance was in order about its use going forward before we go too far down the path.
> 
> 
> I definitely agree some guidance on lambda formatting is in order, and also some guidance about how to format them if they are inside a function call (like the example above).
> 
> -Ian
> 
> On Fri, Jul 12, 2019 at 12:28 PM Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>> wrote:
> We already have a lot of classes which use both.
> 
> FWIW, the wxWidgets folks encourage Bind.
> 
> As for lamdas, I think they’re pretty rare (for this use) in the code at present.  But they do appear to result in a higher signal-to-noise ratio for very short handlers.
> 
> While we’re on the subject, we have a lot of lamdas which use K&R style opening braces.  Are we OK with that, or should they be consistent with functions, blocks, etc.?
> 
> Cheers,
> Jeff.
> 
> > On 12 Jul 2019, at 10:46, Simon Richter <Simon.Richter@xxxxxxxxxx <mailto:Simon.Richter@xxxxxxxxxx>> wrote:
> > 
> > Hi,
> > 
> > On Fri, Jul 12, 2019 at 11:11:21AM +0200, Ian McInerney wrote:
> > 
> >> Other windows seem to use the Bind method with lambda functions for these
> >> small functions, and I have used them as well for some new bindings for the
> >> actionization when needed. My main question is, is it acceptable to also
> >> transition existing events (unaffected by the action changes) to use this
> >> paradigm?
> > 
> > Which registration method is used is completely internal to the class that
> > handles the events -- the same file contains both the registration and the
> > handlers. IMO, it should be consistent within one file (i.e. if there is a
> > table, it should be complete and not be augmented with additional runtime
> > bindings), but beyond that it doesn't really matter.
> > 
> > wxWidgets 3.0 generates a few warnings about initialization order of static
> > objects on MSVC when we're using tables, but these seem to be both harmless
> > and fixed with wxWidgets 3.1.
> > 
> >   Simon
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>