Hi,
I recently had a client request that the column widths he set for a list view should be persistent, so that each time he opens up the application, the widths appear as he left them. This was accomplished in Visual Studio 2003 by dynamically writing the column widths out to a config file using XML. As the list view was being used many times within the application in conjunction with various controls, entries were added to the config file at runtime. It was not practical to define these entries in the config file at design time.
More recently I have been upgrading the application to .NET 2.0, and I have noticed that the My.Settings object can be used to store persistent user information. This is by far a cleaner way to achieve what I am trying to achieve, however, it appears that to use the My.Settings object, the resources that are being used must be set up at design time. This is no good for people like myself, who need to set up the resources at runtime.
I have tried some simple code like the following:
Try
Dim prop As New System.Configuration.SettingsProperty("PropertyName")
prop.Attributes.Add("key", "value")
' Add to existing My.Settings properties collection
My.Settings.Properties.Add(prop)
My.Settings.Save()
' Not sure if this is required
My.Settings.Reload()
Catch ex As Exception
' handle error here
End Try
This code runs without generating an error, however the newly created property is not added to the existing My.Settings resources. Is it not possible to dynamically add resources to the My.Settings object
dynamically adding resources with the My.Settings object
giroff
Jack,
Binding is something I've been burnt with in VB.6 solutions, however I'm more than happy with Microsoft Access databinding. I'm testing the new vs2005 databinding (cautiously) with an application migrated from vs2003, mainly to replace my own record navigation control.
While I accept your binding option above, applications evolve and *.config files need to add new configuration properties. Deploying those new *.config or My.Settings.xxx values needs to be an easier task. When the upgraded application is deployed via an MSI, the *.exe.config file is not upgraded (well mine isn't). This is good, in some respects, because I don't want to kill key config information like Database connection settings, but bad, because I've got to manually edit a *.config file with the .net xml namespaces (vs2003 soln) and force the new setting into those files. Our company builds changes into applications almost daily and deploys those changes to various clients and hundreds of users. I must admit to a very high failure rate with .config file changes and associated application failures when those values are not found (hence my dismay).
I hope that the .net team would consider the evolving nature of application and extend the configuration namespace to help with this upgrading.
My own research shows the My.Settings.Reload and My.Settings.Save methods as potential solutions to some of these evolving .config problems, but I've yet to test the options.
Geoff GB
I agree with David, the underlying solution to a simple problem, like added values to users.config file should be a single line of code (eg. my.settings.user.new(name,value)). I spent a day trying to find an simple solution to this problem.
The new settings option show some fantastic productivity options if you declare the Settings Application/User in the IDE. However who wants to do that when you really want the code to be just saving the values to the Users.config file.
Eg. Store the last position of the windows form. I'd just code it into a base form and or on the close event and save it against a dynamically named setting.
Perhapes David and I are just frustrated with the poor example code provided in this area by the Microsoft Visual Studio 2005 team. The enhancements to VS 2005 with settings has shown great potential, but again, straying of the path become hard, very quickly.
Sharmila Vijayan - MSFT
You can try the following
Holistic
Jack,
Thanks for forwarding the opinion to the features team.
Our company and many of our strategic partners have invested heavy in Microsoft.net and we see the evolution of that product as our best way forward supplying software solutions to companies. We are an ISV partner with Microsoft and hope that we can influence Microsoft on how the .net framework can evolve to be the best software development platform.
Our current client has invested considerable $$$ with our company to build an unique windows application based on vb.net/sql 2005. Hopefully the .net enhancements will be comming fast and strong to make all our jobs easier. Keep up the good work Microsoft.
Ahmed Amer
Unfortunately VS2005 does not support dynamically adding settings into My.setting, but it has a winForm binding feature which can reduce code and the design time complexity.
A good tutorial http://msdn.microsoft.com/msdnmag/issues/05/07/My/
Brian B.
Jamie,
Thank you for the valuable feedback. I have forward your opinion to the feature team.