So far I've always been a great fan of the USING statement. Mostly because it tremendously increases readability of code, especially when working with the very long Infragistics type names.
Today I've face a new, good reason for using it. I'm staying with a customer right now. They are using our GUI for .NET/OERA framework, a set of OOABL classes, components and User Controls, that I know very well (I've written most of it myself). Compilation on my PC is always very, very fast. Compilation on one of the customer's PCs was a nightmare. Like 5 seconds or even longer for a smaller class, causing the whole compilation to be at least 10 times slower than on every PC I knew. Source code was remote, I advised to have that locally - but still no good improvements.
The propath contained 10 references to legacy code directory, which for a number of reasons (which convinced me for now) had to remain on a network share. All Propath entries were at the end.
When we finally got the idea to add the "FROM ASSEMBLY" option to the USING statements pointing to .NET assemblies and also added a couple of USING statements including the "FROM ASSEMBLY" option to assemblies that were referenced from VisualDesigner generated code or where we referenced the full typename in the code it dramatically improved the compile time!
Looks to me - and documentation suggests so as well - that the compiler will search the full propath for OOABL classes before looking for a .NET class in the assembly. With the huge amount of different .NET classes referenced in the average GUI for .NET program that has a huge performance penalty when network shares are involved.
I ended up adding the FROM ASSEMBLY OR FROM PROPATH to each and every USING statement.
USING Consultingwerk.SmartComponents.Base.* FROM PROPATH .
USING Consultingwerk.SmartComponents.Enum.* FROM PROPATH .
USING Consultingwerk.SmartComponents.Interfaces.* FROM PROPATH .
USING Consultingwerk.SmartComponents.Resources.* FROM PROPATH.
USING Infragistics.Win.UltraWinToolbars.UltraToolbarsManager FROM ASSEMBLY.
USING Progress.Lang.* FROM ASSEMBLY.
In Form designs, from now on I'll also add the USING statement to reference namespaces and assemblies used by generated code - even when the source code fully references the class name.
Only the USING statements allows you to point the compiler directly to a .NET assembly OR the propath for any given class.
In Form designs, from now on I'll also add the USING statement to reference namespaces and assemblies used by generated code - even when the source code fully references the class name.
Only the USING statements allows you to point the compiler directly to a .NET assembly OR the propath for any given class.
Nice.
I wonder if OEA can't be enhanced to automatically add "FROM ASSEMBLY" or "FROM PROPATH" to classes it knows about (from the toolbox, say). I would think that the editor already knows this information.
-- peter
I wonder if OEA can't be enhanced to automatically add "FROM ASSEMBLY" or "FROM PROPATH" to classes it knows about (from the toolbox, say).
You should know better than I, what might be added to OEA, right :-)
I'd say it should be technically possible, when the priorities are set.
And while we're talking about it. That's another reason when the folding USING statements in class files stinks!
A developer should care more about them, as it is suggested, when the tool actually hides them...