If trying to free a pointer from another dll in a clr dll, operator delete(_Ptr)
causes stack overflow exception. The call is   call  dword ptr ds:[07C0E8F8h]

Passing to an unmanaged function more bytes than it expects can make the clr debugger crazy.
When the unmanaged function returns it does not recognize the clr code lines that follow,
even if they are being executed normally. The program shuts down in a "fulminante" way
(even without a message from the OS). Debugging the unmanaged code past the return
does not help very much, and it may take hours to spot the error.

Font1.ScriptsOnly=false;	//Esto est documentado al revs

Value type members of classes are due to strange limitations when accessed from other classes
and passed to fuctions.

If a new thread is created but its window is not shown and the order to terminate the thread is sent
to that thread, the closed thread will actually be the main one, i.e., the program closes.

Not does CreateControl nor CreateHandle force the creation of the handle and hence of the window,
both for the .NET and for Windows. This is a very severe bug.

If OnPaint is overriden by first calling base.OnPaint and afterwards painting with our code, the painting
by the .NET will happen the last one, and what we paint will be immediatly replaced by the black background.
The only way to overcome this is to capture the WM_PAINT message from windows, then calling 
base.WndProc, to force the .NET to finish everything it wants to do, and then calling our code.

Everytihg having to do with threads, windows and messages is broken. They pretend that the .NET is
OS independent, but they have mimicked so much Windows that they didn't bother to build an
implementation that behave as documented, but just pass everything to the native Windows,
interspersing the OS and the .NET thus creating a dissastrous implementation, where the impredictable
behavour depends upon that mixture and is by no means as documented, if documented at all.

More on this: From 2010, march, 25 there is a known bug in my program due to a bug in the .NET. If
the message to change the language is sent to a Window that has not yet been displayed, if afterwards
any control gets added or some other change is performed the program generates an exception and closes.
Even if we capture the message and immediatly return, the error persists. Maybe it is because of
getPanel(i)->Handle at Master.exe.

In ListBox.FindStringExact(string, int), and I suppose that the same happens in ListBox.FindString,
if we call the function like MyList.FindStringExact("foo",i) and suppose the number of elements
of the ListBox to be n and i=n-1 in the call, then the exception ArgumentOutOfRangeException
is raised. But it should be raised only if "The startIndex parameter is less than zero or greater
than or equal to the value of the Count property of the ListBox.ObjectCollection class."

It is not clear what PaintBakcground is exactly supposed to do, much less when and how it is called.
The same can be said for the layout. I have still not been able to perceive any difference between
a code enclosed in SuspendLayout, ResumeLayout and the same code with those lines removed.
It is not documented what the pending request to which ResumeLayout(false / true) refer could be.

Controls.Remove(A) no me funciona. En su lugar tengo que escribir A.Parent=null;

Setting AcceptButton when a button has already been pressed does not produce any effect.
NotifyDefault(true) makes the button to display itselft as if it had the focus, but the focus is
retained by the latest pressed button. The right effect can be achieved by simply doing
Buttonx.Focus(), but this is not possible if the form is not currently visible. A change
to AcceptButton should send the focus to the button if the control currently receiving
it is another button, even (specially) if the form is hiden.

Al cambiar el idioma:

Error al registrar DragDrop. ---> System.Threading.ThreadStateException:
El subproceso actual debe estar establecido en el modo de subprocesamiento controlado
simple (Single Thread Apartment, STA) para poder realizar llamadas OLE. Asegrese de
que la funcin Main tiene marcado STAThreadAttribute.

O sea, que el registro de DragDrop est mal implementado, poque no puede ser que dependa de algo
que es especfico del SO y en Windows falle.

ScrollToCaret es ignorado si el control no est visible, y luego al pinchar en la pestaa o botn que
lo hace visible, el control no est situado en la posicin del cursor. Est documentado, pero es absurdo.

Si al tratar el evento VisibleChanged con Visible=true ejecutamos ScrollToCaret(), no tiene efecto
es que todava no est visible el control?. Por otra parte, si lo que tratamos es el evento GotFocus,
la primera vez que se muestre el control este evento no se ejecuta, sino que lo hace cuando pinchamos,
y para entonces es posible que ya hayamos movido la barra de desplazamiento a otro lugar. Ms an,
en este caso controlarlo mediante VisibleChanged s que funciona. Por ltimo, controlar el evento
Enter no funciona nunca. El manejo de ventanas y mensajes es un DESASTRE!!
