Just if you haven't noticed already. You can workaround this if you Shift-Click on your controls one-by-one and then when you selected all of them select create local variable, in this case it would create all of the local variables at ones in the same order as you selected them.
I fullt agree, this has annoyed me several times! Also it's really easy to create bugs if you're not careful as you assume they'll have the same order!
/Y
G# - Award winning reference based OOP for LV, for free! - QestitVIPMGitHub
I have come to the conclusion that this kind of nonsensical layout (which also occurs when creating VIs, or creating controls on the FP, etc) is deliberate and intended to preserve Darren Nattinger status as world-fastest LV programmer due to his knowledge of hundreds of shortcuts to quickdrop macros that provide workaround for these annoyances.
So, I think what you're asking is that instead of creating a stacked set of local variables, you would want us to create a set of local variables that are scattered around using the same relative positioning of the FPTerminals. Thus if the original FPTerminals are in a stack then the local variables will be in a stack. But if the FPTerms are scattered, then the variables will be scattered.
Is that correct or are you proposing some other smarter algorithm? I ask because using the relative positioning of the FPTerms was rejected during the design of this feature since it leads to this arbitrary shape of created objects (especially since the FPTerms and the local variables are not the same bounds). Yes, it helps if the FPTerms are arranged in some "nice" shape but it hinders in other uses.
Is it your opinion that the nice shape is more common usage and sufficiently more common to justify scattering the irregular uses?
I'd make the argument that the order of the resulting local variables that are created shouldn't even matter. If you are creating local variables, it is because you are going to drag them off and use them elsewhere. There is no reason they are going to stay right where they are in any precise order.
I do not think the shape is the issue, but rather the relative y position. I have never performed this operation in anger (ie. for real), only to play around. I like the stack, I like that it is placed on the cursor so I can plop it down where I want, I would not mind if they were stacked by y instead of z.
The problem was created by the recently introduced ability to create multiple objects (not only local variables) at once. As AQ said somewhere, NI's strategy is in par with pretty much every other software companies, i.e. release a beta version and fix bugs in subsequent releases.
So yes, if you have a bunch of objects on the FP and you create derived objects from a group of them, it is easier for most brains to have them presented in the same order (which, would you know it, has probably been carefully layed out by the developer instantiating the objects). If these are objects created from the FP, don't go and hide them in outer diagram space or in the umptieth case of a case structure...
All this BTW would be solved if you had a natural repository of newly created but unused objects like in the WebUI builder. If people want to drop the objects on the BD right away as it is now the case, provide them with the option.
