UnknownReference

Another .TEXT Bug.

I have used .TEXT from systems that do not have .NET framework installed and i should say that the engine behaves really weird during those sessions. It occurred to me today that the only thing that was common to the system from which i made a post today and the one from which i had made a post earlier was that both of them did not have .NET installed on them. And both of them showed the same weird characteristics in the EditPosts.aspx page from where we post to the engine. The FreeTextBox control on the page seems to behave differently depending on whether the client machine has .NET installed or not. If the client machine has .NET then no problems whatsoever. If not, then the FTB shows a textbox without all the helper toolbar containing Font, size, alignment, bulleting and other stuffs. Also the Design and HTML buttons at the bottom of the textbox dissapears. I realised that the Textbox shown during such situations expects the HTML to be typed directly onto the textbox and if no tags are given then it renders the post unformatted !

My question is that 'Why would such a control be developed which would in anyway be dependent on the software installed on the remote client machine and then act differently according to the software installed ?'. I can perfectly accept if the software dependency is on the browser which is going to render but other than that it does'nt make sense at all. The whole idea of creating such blogging tools was to create a common application which will enable the end users to have the same experience with minimum effort and allow them to blog from anywhere eventually ! It in turn makes the experience not dependent on the machine because of non-availability of software which needs to be installed for blogging such as bloggar and other similar ones, but instead centralises the experience and makes them comfortable. Now if the blogging tools in the net are going to behave differently based on the client machine at various times, then where is the customisation and having the at-home feeling necessary for good blogging ?

I haven't had time to look at the .TEXT source yet and so havent been able to figure out the reason for the dependencies of the FreeTextBox on the machine. But if someone is already deep down into it, then you could upload a new release of the .TEXT version along with so many other changes which have been talked about in the .TEXT mailing list recently.

MessageBox bug ??

Has anyone ever tried to place a messagebox at a particular position or part of the screen ? Have you noticed any weird behaviour with messageboxes in .NET ? I was recently browsing the experts-exchange site and i found a question about positioning messageboxes.

It said that owner parameter in the MessageBox's static method, is not being considered at all while showing the actual messagebox. Here's the actual syntax for the messagebox's Show method.

public static DialogResult Show( IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options );

Now say inside a WinForm's Load event, if i call

MessageBox.Show(this, "Hello World !");

where this stands for the 'owner' here of type IWin32Window, meaning that the messagebox should be the modal dialog for the current window and it should be displayed in the center of its parent. But the weirdest part is yet to kick in. For some reason, even if you pass or set this parameter, it is being ignored or not considered and only the default window or the ActiveDesktop window is being taken for the IWin32Window. So what happens is that the MessageBox always shows up in the center of the screen and not anywhere else.

I think i have found out the reason for this bug or whatever the flaw is .. The MessageBox class in System.Windows.Forms namespace has a private static method with the signature

private static DialogResult ShowCore(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options)

This method basically checks whether the owner is null or not and then it calls the MessageBox function in the User32.dll ... Now if the passes owner to this function is null, then the activewindow handle is taken and passed on to the nativemethod call. The MessageBox then calls the SafeNativeMethods.MessageBox and passes the params that it has obtained which in turn is a wrapper around the system's MessageBox function.This function takes the window handle as one of its parameters but i think internally this is always pointing to the ActiveDesktop window's handle ... that is why the messagebox always ends up popping in the middle of screen instead of the middle of form ...

To test this out and to confirm it, i checked out the MsgBox function in VB and voila ! It gives the same expected behaviour of placing the messagebox right in the center of the screen and never on the activeform as the implementation should have been.

So basically unless MS changes the user32.dll this problem cannot be solved wrt messageboxes.

I feel releived on finding that this is NOT A BUG in the framework as many have suggested in some of the newsgroups !!