So you think you can hide...

Wanna hide some sections of Sharepoint to change the look of your page...

Maybe you wanna check this snippet... Tells you most of them... But you'll need to do this by adding this pieces of code into a web part so that if it's used within the page... It would hide those elements... ;)

In other words, injected code... :D

Referrence: http://hardeepm.spaces.live.com/blog/cns!7877E3B0A44BBBF!156.entry

Your window.onload may cause problems in Sharepoint !!

Looks very smart of Sharepoint designers to have the scripting functions run in a systematic organized way... Personally, I love organization... Makes things defined and in order, not just haphazardly..

Sharepoint works as follows...
onload="javascript:if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();",


So if one would like to execute some function onload of a page... doing so:
window.onload = function()
would really cause him trouble since he'll overwrite the sharepoint function calls...

So the smart way of doing this is to use:

_spBodyOnLoadFunctionNames.push('myFunction_01');
_spBodyOnLoadFunctionNames.push('mySecondFunction');

This is how sharepoint really works ;) :) So we're following their way and voilaaa...

Reference: http://blogs.tamtam.nl/mart/UsingWindowonloadInSharePointPages.aspx

Heck...Parser error all of a sudden

Newbie in Sharepoint I got this error... Immediately afterwards, I had to say OUCH... That's because I simply did nothing to get an error... I was only trying to create a new master page to use... That's all :))
I even undid any changed and still the error was there...
It said the following:

Parser Error Message: Data at the root level is invalid. Line 1, position 1.
Source Error:
Line 1:
Line 2:
Line 3:
Source File: /App_Browsers/compat.browser Line: 1

After some searching, I found the cause of this really strange behavior...
Some folders are created named "_vti_cnf" just beside the file "compat.browser".
This folder contained another compat.browser file containing some metadata. I
deleted this folder and this fixed the problem.

However, I hope this doesn't cause more troubles... If I find out anything, definitely I'll post it here :))

Determining the size of .Net Managed objects residing in memory

Lately I've been checking how to test for memory performance issues and I was hit by Mark Brown's blog... Liked his snippet alot although it's not thread safe but still it can help...
Here's the snippet:

long StopBytes = 0;
foo myFoo;

long StartBytes = System.GC.GetTotalMemory(true);
myFoo = new foo();
StopBytes = System.GC.GetTotalMemory(true);
GC.KeepAlive(myFoo); // This ensures a reference to the object kept in memory

MessageBox.Show("Size is " + ((long)(StopBytes - StartBytes)).ToString());

However, I guess it would be better if one would get the StopBytes after the statement of KeepAlive... Don't you think?