Month: July 2004

In Visual Studio 2005, if you have a windows form and have a fair amount of threading going then that things can get pretty frustrating. As you know, because of the way that Windows handles its user interface, you should only be updating the user interface from the main thread. If you try to do it on other threads, bad things happen, and they can be pretty hard to track down. Windows forms includes some code to detect when that is happening, but it can’t do it in all cases. When you get in this situation, you need to call Invoke() on the form, and pass it a delegate to the function that you want to be called on the main thread. Eric discusses this in detail which is a recommended read if you play with a lot of threads on your Win Forms.

If you don’t know what Wings is, then read the earlier part of this series. There have been a number of changes since Part 1 and this part, namely the release of a new Longhorn build. For the Assemblies you will usually need the System.Storage.WinFS.dll assembly in most of your projects. It represents the basic interfaces and classes (for example, Item and ItemContext). In addition, System.Storage.Core.dll is required for most Wings work. Once you have both of those assemblies, most of the functional groups are separated into separate assemblies. For example, if you are working with Contacts, you will need the System.Storage.Contacts.dll assembly; if you are working with Files, you will need the System.Storage.Files.dll assembly. On some rare occasions, you will also need the WindowBase.dll assembly. This assembly contains much of the core Longhorn-specific content. All the Longhorn assemblies are now located in one place: \Microsoft.NET\Windows\v6.0.4030 (depending on the current version of the Longhorn assemblies).

Searching – Before you can work with Wings objects, you must first be able to find them. Searching Wings is fairly straightforward. It uses the OPath syntax that is part of ObjectSpaces. Searching within Wings begins with the ItemContext class. The ItemContext class supports a FindOne method that will return the first object that satisfies the search. The FindOne method takes a Type of the objects we are searching for and the OPath search string. FindOne returns either the first found object or null if no matches are found.

What is OPath? OPath is a specialised syntax for dealing with object graphs. OPath is made up of XPath sprinkled liberally with SQL syntax. At its most basic, OPath supports property comparisons. Microsoft has attempted to create a simple and powerful search language by merging ideas from XPath and SQL. Using OPath you can do:

• Property Searches
• Wildcard Searches
• List Searches
• Collection Element Searches
• Compound Searches
• Relationship Searches

You can learn more about the OPath here.

Conclusion:

Wings makes searching and manipulating Wings objects very straightforward. Searching through Wings allows us to specify a very simple syntax for most cases but supports a rich search syntax to perform complicated searches when needed. Searching by specifying the type of object we are looking for allows us to use the hierarchical nature of the Wings schema to our benefit when searching. In addition, the Wings API allows us to deal with Wings object like any other managed objects when we need to manipulate them. In most cases we can deal with Wings objects just like any other classes that we work with in our applications. The power here is that the API should be very intuitive for users of Wings objects. We can create objects, change objects by manipulating properties, delete objects, and save our changes in batches.

For more information check out:

• http://tinyurl.com/3zksb
• http://tinyurl.com/4x79s
• http://tinyurl.com/4td5t
• http://tinyurl.com/6louv

Unfortunately it is not. The UI is better – but that is just the new resource files used with cooler icons (compared to the previous version), but VSS itself is as limiting a product as it has been till now. I remember asking one of the product managers of VSTS on VSS when I was in Redmond, and they had said that it will be a completely revamped product – something which Microsoft internally will (or can – I forget now) use in the product development teams and should be able to compete with ClearCase, CVS, etc. But I guess, Beta1 ships with the same old useless source control.

But till the “real source repository” ships, for most small development teams VSS is still not a bad product and is quite useful in those situations. I have not checked out the API so am not sure if that has changed, but I would assume (quite safely) that it is the same. For those who are curious to see how the GUI has changed, here are some screen shots below.

Adding a File to VSS – Well the dialogue boxes also have not changed, with the Folder and Drives view still from the old Windows 3.x days!! If you have a deep hierarchy it does make is a big pain to navigate. Not to mention long filenames that do not fit in the listbox.

VSS File Menu (Context) – Again the same as before except newer icons.

VSS Toolbar:

VSS Working Folder:

VSS About:

VSS Application – As you can see below, the changes are only cosmetic but everything else is more or less the same. Click on the image below to see the fullview.

Update: Intead of scaling down the image for the client I moved it right to the end of the post as it was spilling over to the content on the right hand side. I also scaled down version and if you click on it then you can see the fullimage.

Since a String class, is immutable and when it is not needed, it cannot be programmatically scheduled for GC or in other words, it is not possible to predict when it will be deleted from the memory that can be a security risk especially if the string contains sensitive information such has credit card numbers, passwords, etc. This is where a new class in .NET 2.0 which ships with Visual Studio 2005 called SecureString comes in. It represents text that should be kept confidential and is encrypted for privacy when being used, and deleted from computer memory when no longer needed.

A SecureString is similar to a String in that it has a text value, but, the value of an instance of the SecureString class is automatically encrypted, can be modified until your application marks it as read-only, and, when no longer needed, it can be deleted from computer memory by either your code or the GC. The value of an instance of SecureString is automatically encrypted when the instance is initialised or when the value is modified. Your code can render the instance immutable and prevent further modification by invoking the MakeReadOnly method.

Note: SecureString has no members that inspect, compare, or convert the value of a SecureString. The absence of such members helps protect the value of the instance from accidental or malicious exposure.