G
G. Tarazi
This is something that I find strange in Microsoft, some departments are going forward and some backward and here are 2 examples:
----
First Example: when it comes to Microsoft Visual Studio.NET 2003 and the typed datasets in particular, everyone will tell you how much time will they save you combined with the intellisense; and that is true.
You will save time by not looking and searching for the node names, they are there as soon as you press the dot in VS.NET.
If you change the schema of the dataset, the complier will not compile the project, and will tell you where the error is.
A simple thing that will save you a lot of development and testing time.
Now back to InfoPath, to select a node, you must use the command "Select Single Node" and an XPath expression inside that command, until here is ok.
But the problem is that I must know the exact XPath expression to select that node, and that consumes time.
Then when the schema changes and it will change so many times during the development, the compiler will not tell me if there was an error in my XPath expression!
Not talking about the processor overload when you ask for multiple select singe node commands, etc.
What do you think a customer of both MS products will think? VS.NET datasets / InfoPath ? (I leave it for you)
---
Second Example: in VS.NET and in every Microsoft product, even in the upcoming release of Microsoft Windows Longhorn, each object have properties and value, both affect who the object looks like, and both can be changed at runtime.
But in InfoPath, only the value can be changed at runtime, the rest require a workaround, like conditional formatting based on a third hidden field, etc.
So, once again, VS.NET is moving forward by unlocking more possibilities and InfoPath backwards by limiting some features.
----
First Example: when it comes to Microsoft Visual Studio.NET 2003 and the typed datasets in particular, everyone will tell you how much time will they save you combined with the intellisense; and that is true.
You will save time by not looking and searching for the node names, they are there as soon as you press the dot in VS.NET.
If you change the schema of the dataset, the complier will not compile the project, and will tell you where the error is.
A simple thing that will save you a lot of development and testing time.
Now back to InfoPath, to select a node, you must use the command "Select Single Node" and an XPath expression inside that command, until here is ok.
But the problem is that I must know the exact XPath expression to select that node, and that consumes time.
Then when the schema changes and it will change so many times during the development, the compiler will not tell me if there was an error in my XPath expression!
Not talking about the processor overload when you ask for multiple select singe node commands, etc.
What do you think a customer of both MS products will think? VS.NET datasets / InfoPath ? (I leave it for you)
---
Second Example: in VS.NET and in every Microsoft product, even in the upcoming release of Microsoft Windows Longhorn, each object have properties and value, both affect who the object looks like, and both can be changed at runtime.
But in InfoPath, only the value can be changed at runtime, the rest require a workaround, like conditional formatting based on a third hidden field, etc.
So, once again, VS.NET is moving forward by unlocking more possibilities and InfoPath backwards by limiting some features.