compare objects in search 1-D array

[robijn]

QUOTE(Aristos Queue @ Jul 18 2007, 11:35 PM)

debate about *which* menu should appear first -- if you popup on a child wire, should you get a single palette with all the methods of child and parent and grand parent? Or should these be separate palettes? Should the parent be on a subpalette or should the child be on a subpalette?

Is this not simply all the available methods for the class of which the wire is ? Hmm, maybe I am now re-raising the debate about whether the wire type should be fixed or adjust dynamically to whatever you connect to it... I think it should be fixed, this should solve your whole problem, the callable methods are known then. You could create a non-obligatory popup to remind the user that he's connecting something wierd, offer him a menu with possible solutions: adapt method to type or keep type (and possibly keep error)... This maintains the strict typing, edit-time checking, and prevents automatic uncouncious adaptations by LV. Yeah, I'm a fan of strict typing...

QUOTE(Aristos Queue @ Jul 18 2007, 11:35 PM)

All in all, I've decided it is low priority -- if you're creating a class to be reused, when you're done with development you can create a palette by hand and set it to appear in the context menus (using the class' property pages). If you're still developing the class, just use the project tree as the palette -- it's close at hand generally.

Yes you're right. Access to VI's to place has never been the biggest problem. I didn't know you could make a class appear in the context menu. Sounds nice.

Joris