.net.devcity.weekly ---

Advertisement

Advertisement

The newsletter is compiled by DevCity.NET NewsMasters XTab and Mike McIntyre

Advertisement

Table Of Content:

Advertisement

This is it - end of the month and your last chance to get your hands on these great prizes:-

  • A Web Site License of .netCHARTING Enterprise Edition ($395)
  • PLUS
  • $100 in Amazon Vouchers?

Here's all you have to do to have a chance to win :-

1. Download the evaluation version of .netCHARTING from their site here.

2. You will see that the package comes with a wide range of sample charts that demonstrate the versatility of this useful application. All you have to do is to look vey carefully at those samples and then simply select the correct answer to this question:-

What is the total number of items reported sold in February for the sample chart drilldown.aspx included with the free trial?

Is it:-

  • a) 4385
  • b) 8435
  • c) 3548
  • d) 3485

You can find the correct answer very easily. But - here's a tip: We've had a lot of wrong answers so far, so take your time and double check your answer before sending it in - some of those numbers look very similar and can easily confuse you if you are not careful!

Send your answer - simply a, b, c or d - to answers@vbcity.com. Good luck!

http://www.dotnetcharting.com/gallery/
Diary of a .NET Newbie: Looking Good, Booking Bad.

One of the really enjoyable things about making the effort to learn a large and complex language like VB.NET is that, as you pass another milepost and master another little skill area, everything around it just falls neatly into place. And of course you get that lovely warm "Wow! I understand that!" feeling when you go back and read other people's code snippets and answers in that particular area. Don't know about you, but I'm still surprised at how often I look back and think "I don't know why I found it so hard to understand, now!"

Of course, one of the reasons why things can be hard to grasp might be because there are some pretty dreadful explanations out there! So there's no reason to be beating ourselves up if we don't completely get the hang of something first time round.

I'll give you an example. Like a lot of VB6-ers, I've never been all that hot with OOP. In VB.OLD you can avoid getting your hands dirty to a large extent; but that's not a luxury you can afford in .NET though. So in the past couple of weeks I've really knuckled down to it and, although I'm no world leader in the game, I've certainly got the basics wrapped up and am wading into the trickier stuff. I can even spell "polymorphic" now without having to look it up :-} On a good day, I can even remember what the heck it means.

I've been using one of the MS Press books to get me up to speed. Fair enough, this is a book that's devoted to this one topic, so you'd expect it to cover most of the important angles. And it does. But, once I'd started to understand the basics, I thought I'd take a look back at some of my other VB.NET Newbies books - you know, maybe pick up an extra titbit or two, reinforce what I'd learned, that kind of thing.

And what I discovered is this: I'm not surprised that I struggled to understand OOP when I came to realise just how badly written some of those "explanations" actually are! In those other books, I still didn't even understand the explanations of things that I'd just fully mastered thanks to my MS Press book.

I suppose the bottom line is this - just because the student isn't understanding the subject doesn't mean the student is poor. Maybe it's the teacher. So, if you're struggling with one aspect of .NET or another, don't give up - just find another source to show you the way.

- Junior (Ged Mead aka XTab, xtab@vbcity.com)

by Mike McIntyre

The System.Environment class "provides information about, and means to manipulate, the current environment and platform." This article introduces the Environment class and through code snippets demonstrates some of its properties and methods including NetBios computer name, OS version, user domain name, CLR version. and path to special folder.

' Environment.MachineName
Console.WriteLine("Environment.MachineName (NetBios) : " _
    & Environment.MachineName)

Result: Environment.MachineName (NetBios) : AZ1

' Environment.OSVersion
Console.WriteLine("Environment.OSVersion (Windows) : " _
    & Environment.OSVersion.ToString)

Result: Environment.OSVersion (Windows) : Microsoft Windows NT 5.1.2600.0

' Environment.UserDomainName
Console.WriteLine("Environment.UserDomainName : " _
    & Environment.UserDomainName)

Result: Environment.UserDomainName : AZ1

' Environment.Version
Console.WriteLine("Environment.Version (CLR) : " _
    & Environment.Version.ToString)

Result: Environment.Version (CLR) : 1.0.3705.288

' Environment.GetFolderPath
Console.WriteLine("Environment.GetFolderPath : " _
    & Environment.GetFolderPath(Environment.SpecialFolder.Favorites))

Result: Environment.GetFolderPath : C:\Documents and Settings\Mike McIntyre\Favorites

This class can also be used to retrieve the following information:

  • Command line arguments
  • Exit codes
  • Contents of the call stack
  • Time since last system boot
  • Stack Trace

To learn more about the Environment class click here Environment Class.

.NET Upgraders: The Memory Mystery

by Mike McIntyre

What do these questions and statements have in common?

Why does my Hello World! application use 12 MB of memory?

I don't think the garbage collector in .NET is doing its job. My application keeps using more memory.

My .NET applications use a lot more memory than my VB6 applications.

I have a memory leak, what should I do?

The answer is: More often than not, the questions and statements come from confusion about how the Common Language Runtime (CLR) and the Windows Operating System (OS) manage memory.

Generous Memory Allocation

Unless memory is in short supply, the OS allocates each running application more than the minimum physical memory required for it to run. The OS commonly give applications like Word and Excel more than a 'just get by' memory allocation. It is just as generous with the memory it allocated to our .NET applications.

Windows OS - If physical memory is not in short supply, the OS will give applications more or less all the RAM memory they ask for. When demand for memory exceeds supply, the OS will take back physical RAM from an application that is not using it to give it to an application that needs it.

CLR - If memory is not in short supply, .NET applications may use more memory than they need. A good example: when a .NET application is loaded into memory, assemblies are loaded in what is a fairly expensive but transient operation. After the assemblies are loaded and if memory is not in short supply, the leftover unused memory from loading the assemblies is left behind rather than being reclaimed.

Working Set, Minimum Working Set, and Maximum Working Set

You many find it helpful to know a little more about memory management on your Windows computer. A good way to start is to learn a little about memory internals, specifically memory working set, minimum working set, and maximum working set. For this article's purposes think 'application' when you see the word 'process' in the definitions below.

Working Set

The set of memory pages that is resident in physical RAM for a given process while it has one or more running threads.

The size of each process's working set is bounded by a minimum working set (minimum number of memory pages that the Memory Manager guarantees to be resident in RAM while the process has one running thread) and by a maximum working set (a maximum number of memory pages of RAM that may be allocated to the process).

However, the NT kernel does not necessarily constrain a process's working set to its maximum working set boundary if many free pages are available. Why? One important reason is that performance wise it is better to over allocate memory to each process if memory is plentiful and only take it away if memory becomes scarce.

More simply you can think of the working set as the number of bytes of physical RAM being used by a process at a particular point in time. This varies according to the needs of a particular process and the needs of other processes running on the same computer. If free memory is plentiful the number of bytes of RAM allocated to a process will be closer to its Maximum Working Set size. If memory is in short supply, this number will be closer to its Minimum Working Set size.

Minimum Working Set

The virtual memory manager attempts to keep no more than this much memory resident in the process whenever the process is active and memory is in short supply.

Maximum Working Set

The virtual memory manager attempts to keep at least this much memory resident in the process whenever the process is active.

.NET Urban Legend

It is possible to reduce the working set size of a .NET Windows Forms application by minimizing and then maximizing the application immediately after it loads. Windows OS trims the working set of applications when they are minimized. The memory that was briefly used while loading all those assemblies mentioned earlier is trimmed by the process of minimizing and maximizing the application.

You can demonstrate this behavior to yourself by creating and running a Windows Forms application with just Form1 and no added code.

1. Create and run the simple application.

2. Open the Windows Task Manager and then its Processes Tab. You will see the Task Manager shows your application's memory usage at approx. 12.5 MB.

3. Now minimize your application and then maximize it. Check the Task Manager again. You will see the Task Manager now shows your application's memory usage at approx. 1.5 MB. The memory that was used to load assemblies when your application was launched was reclaimed by memory management when you minimized the application.

Did you improve memory management or application performance by minimizing and maximizing your application? No.

You can find some .NET Windows programmers who add code to minimize and then maximize their programs thinking that they are optimizing memory. As these programmers have shared this technique with others a sort of .NET Urban Legend has been born - a programming practice based on fiction not fact.

This practice is unnecessary because when OS needs the unused memory left behind when the assemblies were loaded it will reclaim it automatically. In fact, decreasing the size of your application's working set when memory is plentiful may decrease performance.

Memory Management Demonstration

One of the best ways to watch the Widows OS and the CLR manage memory is to conduct a memory stress test.

Below is an excerpt from a post I made to the Microsoft .NET Framework newsgroup in the fall of 2002. Try the "experiment" I outline in this excerpt for yourself to witness the some of the memory management dynamics of the OS and CLR. Here is the excerpt.

"I have not had any memory issues with the Win Forms applications I have developed. But I have seen many forum postings expressing concern about how much memory .NET applications consume and I became more and more curious why so many posts like this were showing up in the forums. The posts I have seen often express concern that even a simple Hello World application may use approx. 12 MB of memory.

I asked a few folks at Microsoft about this. I was told that if RAM memory is plentiful, an application may grab a very generous chunk of it. An application will not be so 'greedy' (my own words) if available memory is scarce.

I performed an experiment. I created the Hello World Windows Forms application, and then opened 51 instances of it. I used the Windows Task Manager to monitor memory usage. On my two year old Dell Latitude, with 512 MB of memory, running XP - here is what happened:

The first instance of the Hello World application took 12.5 MB of memory. Until I got to around 41 instances, each instance I opened took another 12.5 MB of memory. Then, with memory getting each instance I opened took less and less memory.

The last five instances of Hello World I opened took 1.7 MB of memory.

I right clicked on the group of 51 Hello World applications showing the Windows taskbar and chose Close Group to force all instances to close down. I watched the Task Bar memory manager as each instance closed in turn. Memory was rapidly returned to the system. In 15 seconds all instances were closed and available memory was back to where it was when I started the experiment."

by John Spano

Now that we know how a CallBack works, we will take a look at how to implement one of our own and call it asynchronously. As usual, we start by defining a delegate.

Public Delegate Sub MyAsyncDelegate()

Next we will show our test code and delegate functions together and analyze them

Private Sub MyWorker()
    System.Threading.Thread.Sleep(2000)
    Debug.WriteLine("MyWorker Done!")
End Sub

Private Sub ImDone(ByVal ar As System.IAsyncResult)
    Debug.WriteLine("AsyncDelegate is done")
End Sub

Private Sub btnButton1_Click(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) Handles btnButton1.Click
    Dim del As MyAsyncDelegate
    del = New MyAsyncDelegate(AddressOf MyWorker)

    Dim cb As AsyncCallback = New AsyncCallback(AddressOf ImDone)

    Dim oState As Object

    Dim ar As IAsyncResult = del.BeginInvoke(cb, oState)

    Debug.WriteLine("After Delegate BeginInvoke")
End Sub

If you look at our two delegate functions, you will see that the MyWorker function is the target of our normal MyAsyncDelegate. The other function, ImDone, takes a parameter of a System.IAsyncResult. This is the signature you need for the class AsyncCallback.

An AsyncCallback delegate allows you to call a function asynchronously. It takes a parameter of the results. In our test code you will see that we have created a variable named, cb, for our AsyncCallback. This is the delegate that will get called when our function is done.

Next we declare a variable, called ar, of the IAsyncResult type and set it equal to our normal delegate's BeginInvoke method. This method takes a Callback delegate and an object that represents its state. This call returns immediately. The framework does all the work of making the call to MyWorker on another thread for you.

When MyWorker finishes, we get our asynchronous sub's output of AsyncDelegate Done. If you examine the whole output, you will see that the asynchronous call return immediately, then the MyWorker sub finishes, and finally the ImDone sub is called.

After Delegate BeginInvoke

MyWorker Done!

AsyncDelegate is done

In our example, we have done all the work locally behind a form, but one could easily define a method that took a delegate for a callback. Instead of defining your delegate variable locally, you would use the passed in one as the target of the AsyncCallback object. After setting up, you would call your internal delegate to do the work and return processing to the calling sub. As your delegate worked, it calls the AsyncCallback whenever you decide to notify the client.

Hopefully this series of articles will help you understand delegates and how VB.NET uses them. When applied correctly, they can make your programming very generic and able to handle many different situations.

The full set of articles will be posted up on VBCity as a FAQ.

Good luck and happy coding!

by John Spano

Every once and a while one comes across a great product that does some needed function very well. XHEO|Licensing is one such. It is a comprehensive set of tools that does program licensing, and it does it very well...

Read the complete review on DevCity.NET

http://www.devcity.net/net/article.aspx?alias=xheolic
Advertisement

Parts 1 and 2 of John Spano's 'Delegates in Visual Basic.NET' newsletter series are available online now! Check them out - Part 1 and Part 2

http://www.devcity.net/forums/faq.asp?tid=41904
Advertisement

We encourage you to pass this issue of
.net.devcity.weekly on to anyone you know with an interest in .NET technology and News You Can Compile

Manage Your Subscription Here.

You are currently subscribed as '*EMAIL*' to .net.devcity.weekly.

Click here to unsubscribe.

Thanks for reading!

DevCity.NET is hosted by FullControl.NET
Copyright vbCity.com, LLC 2003. All Rights Reserved.