Google WAVE. Got the invite a week back. was realy excited to check out all the features i had heard about and watched about it in Utube! but Damn it was disappointing The UI is DAMN not for a intuitive user kindah! Took five google searches to find how the heck i got 2 invite ma frnds into Google WAVE.
Once u mute a WAVE, stil i am unable to find a way to UNMUTE!
Moreover, am still finding hard to figure out how to see that most promised feature of REAL TIME TYPING VISUALIZATION! where you see waht characters your friend is typing before even he hits Enter/Send!
So far, i could totaly say its a Real Hype and a TRUE BETA! the least first product which amused me the least from Google!!

This week was interesting with an issue -> SCSF memory leakage along with other issues on the IIS !  As i had stressed in my other blog posts, SCSF is awsome with lil bugs in itself, we users coding things with out knowing it completely is a HUUUGE mistake. All we end up doing is lot of mistakes and one among them was  making the GC luk like a pathetic Goose, who cant collect any of the objects from memory. All due to the wonderful hot wiring of objects we did so unintentionaly!! ;)

We had lot of issues pertaining to the view not getting disposed, one fix was done as said in the codeplex thread, http://www.codeplex.com/smartclient/Thread/View.aspx?ThreadId=18386
but on immediate apply of it, dont be surprised if you get a Stack overflow exception when you have Layout view with multiple views inside them! To fix it, you need to skip overriding the The OnCloseView of the base presenter, and have your custom method say
public void CloseTheView()
{
//and call the base closeView in it.
 _presenter.CloseView();
}

You will know why i am asking you to do this, by jus debugging once you get the Stack overflow exception ( make sure you uncheck Just My code option in the Debug section of Tools ->Option)

Our first doubt landed on the base class which was coded in the last and applied to every view. I didnt like it, not tat i am hater of base classes.. Just that the base view coming in the last days and asking every view to inherit from it was not a gr8 idea in  ma point of view. The base had some event hookings and those were not geting removed for inner views. Coz, when the layout View ( which contains the innner View) starts closing the Me.Parentform will be already gone, and when the Layout closes it triggers inner guys to close. At that time when the inner guys try to remove the handler from the Me.ParentForm, that instance wont exist. So it cant remove its handles from it. GC wont remove the inner guy coz, there is a event handling hot wired which prevents it from doing its work.

We almost nailed this as the bug, but then one module wasnt shaking at all. We were stupified, and we even ripped that module apart. Finaly found a THREE line code in it , which had a SCSF Command Handler hot wired from the View to the Module Controller!!!!
Usually we hot wire Command Handler from Parent to child. But here it was done in the reverse. The Module Controller is gona live until the Application exits. Hence, the views were NOT geting released by GC at all.
We added code to remove invokers before we tried to close ourselves. and now things are almost perfect.. Worse truth, this requires few more weeks if not months of testing to be sure that the current patch didnt cause any further troubles!

Thanks to the memory profiler, we got the Disposed objects stil in memory list , and from that we dug out the Object Retention Graph. Though it dint tell the exact problem in plain english it supported our suspicion  and led us in the right direction. I tried to use the CLR profiler, manh it jus gave me a dinausors DUMP! :P ;) i had no space left, so had to skip using it.

Finally i got some time to relax and even to blog ;)