Salut. I don't remember who posted something that looked like this, but somebody talked about putting all the constant in a cluster constant(favorably a TypeDef) plugged to an indicator of the same typedef, in a vi, and then accessing them with the unbundle. So you end up with only one file containing all your constant and an easy way of accessing/adding them. Your also not limited by connector pane connections.
Can someone point me what are the problems with that solution? Dominic Lavoie Chef du groupe logiciel\Software group leader mailto:[EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Menjoulet, Scott Sent: Thursday, June 17, 2004 12:20 PM To: George Gatling (Contractor); info LabVIEW Subject: RE: Wanted: #define How about putting all constant in subVI's as discussed and then creating a Polymorphic VI from all the individual constant VI's? Then you only need to drop one VI and you get access to all your constants from a simple right click menu. In LV7, you can even show a selector menu right on the diagram that gives you even quicker access to all your constants. I've never done this, but I just tried it out and it looks like it should work pretty well. I think this solves both the desire for succinctness and easy access to editing. You can open up the poly VI, select an instance VI and edit it. Or edit the instance VI directly from the diagram. Either way, only slightly more than a *handful* of clicks. Adding a new VI constant could be easier. It would be nice if the Poly VI supported having a template from which you could easily add/create a new instance. Sure, there is still a separate file for each constant to manage, but to me this approach would mitigate the value editing and diagram readability/selection issues. The question is now whether using constants from polymorphic VI's in this manner still benefits from the in-lining optimization? Steve, care to comment. Scott Menjoulet Texas Instruments Inc -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Gatling (Contractor) Sent: Thursday, June 17, 2004 10:55 AM To: info LabVIEW Subject: Re: Wanted: #define Seems to me the general consensus is that constants should be sub-vis, and since there could (will) be many of them, they can be collected together into a subfolder under the application. This does achieve some of the advantages of the #define: the constants are collected together in one easy to find place, changes to the constants are easily propagated throughout the application, and there is little (if any) performance penalty at runtime. The downside? Well, if you told a c programmer he had to have a different *file* for every constant he probably wouldn't stop laughing for a couple of years. And there is considerably more of an editing headache... #define is a handful of keystrokes... the vi constant method is about a hundred mouse clicks, editing an icon, saving a new file, and bringing that file onto whatever diagram I was working on (which I can remember anymore). George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax) Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may contain privileged information. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. Information confidentielle: Le pr�sent message, ainsi que tout fichier qui pourrait y �tre joint, sont envoy�s � l'intention exclusive de son ou de ses destinataires; ils sont de nature confidentielle et peuvent constituer une information privil�gi�e. Nous avertissons toute personne autre que le destinataire pr�vu que tout examen, r�acheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'�tes pas le destinataire pr�vu, veuillez en aviser imm�diatement l'exp�diteur par retour de courriel et supprimer ce message et tout document joint de votre syst�me. Merci.
