Endless loop on OLE Drag and drop

[godeny]

Hello TiKu,

i have a problem with your Unicode Edit Control.

I use the control in a control array (you surely not used it so, because the OLESetData event has a parameter named "index" - it is a name collision with the standard index parameter in case of control arrays), and the control array is placed on a picture box, which is in a user control. If i drag a text from the control, at the moment, when the mouse leaves the control, there is an endless loop somewhere in the control - the CPU usage is 100%, i can only abort the program with the task manager.

I've created a small test from your sample, which has this problem.
There are 4 edit controls there. The ones on the picture box, but not in a user control seem to be functioning, as far i do not move the mouse into the area of the user control - then happens the same thing. If a try to drag a text from inside the user control, then it dies.

Please can you check, what is the problem ?

Zoltan

[TiKu]

The problem is the Forms 2.0 Label in the UserControl. If I remove it, everything works fine. Forms 2.0 controls aren't made for VB6, so I guess it's a Forms 2.0 bug and no EditControls bug.
BTW, you are not allowed to distribute Forms 2.0 with your program.

But I've detected another bug: The DEL key isn't working inside the TextBoxes and you can't use TAB to cycle through the controls (it stops working at the last one). I begin to hate COM.

[godeny]

Thank you, TiKu.

I've experimented with Forms 2.0 before, but when i found your controls, i've removed all the Forms 2.0 controls from my project. It looks like i've forgot to remove the label - as it had no caption, i did not noticed it (Now I am using a picture box instead of the label controls, writing the caption with API calls on it - as i use also OLE Drag and Drop with the labels.).

In my large application the TAB key is functioning - after the last textbox it jumps to another control outside of the user control, and comes back correctly -, but the DEL key is not working.

[TiKu]

I've attached Beta 1 of version 1.2.0. It has better drag'n'drop support, smaller binaries and faster event raising. I've also fixed the DEL key bug.

I've changed many code to improve its quality. E. g. the property page has been completly rewritten (still looks more or less the same though). So please let me know if you come across any new bugs.

[godeny]

Hello Tiku,

it seems me (i've replaced 1.1 with 1.2, so it is not so easy to check the 1.1 once more), that when i dropped something on an empty edit box, then the GetInsertMarkPosition responded either with impAfter or with impBefore. Now it responds with impNowhere - i had to extend my OLEDragDrop event handler.

But this is the only small difference i've discovered yet - 1.2 works for me. As i have until now only single line edit boxes, i cannot say anything about speed.

The DEL bug is really fixed.

Thank you

Zoltan

[TiKu]

Hi,

thanks for testing.

it seems me (i've replaced 1.1 with 1.2, so it is not so easy to check the 1.1 once more), that when i dropped something on an empty edit box, then the GetInsertMarkPosition responded either with impAfter or with impBefore. Now it responds with impNowhere - i had to extend my OLEDragDrop event handler.

I don't see which change in the code should have caused this and have not tested whether the control really returned something different in previous versions, but I've changed the implementation to return impBefore and char 0 if the coordinates are within the client area and the control is empty.

BTW, the insertion mark stuff (and some other things) won't work properly if the control contains more than 64k characters. This is caused by limitations of the underlying Edit control of Windows. I'll update the docs to mention this.

TiKu

[godeny]

BTW, the insertion mark stuff (and some other things) won't work properly if the control contains more than 64k characters.

I've planned to rewrite my "timetable editor", to change the underlaying control from CodeMax (not supported since years, and the VB control is not Unicode) to your Edit control.

Is there a way to handle things, if the text is longer as 64k char (128 kByte) ?

Zoltan

[TiKu]

The problem is the underlying edit control. Important parts of its API aren't designed for texts that large. Two examples:

1. EM_CHARFROMPOS. This message retrieves the character nearest to the specified position. It expects the position's coordinates to be passed in one single 32 bit integer - the x coordinate in the lower 16 bit and the y coordinate in the upper 16 bit (in client coordinates). This limits x and y to a range from 0 to 65535, which isn't that much for scrollable controls. The return value of this message holds the character index in the lower 16 bit and the index of the line containing the character in the upper 16 bit, so these values are limited to 0-65535 as well.
   It might be possible to use the line index (which grows slowlier) to calculate the character index for values larger than 65535. This would shift the limit a bit. But this wouldn't help much, because there's still the problem with the coordinates.
2. EM_POSFROMCHAR. This message retrieves the position of a character. The character index is passed as a 32 bit value, so no problem here. But the coordinates are returned as a single 32 bit integer (lower 16 bit = x, upper 16 bit = y), so we run into trouble again.

As far as I remember, there are more EM_* messages that use 16 bit integers when 32 bit integers would be much better. Any feature relying on such a message won't work properly if the control contains more than 65535 characters. Unfortunately EM_CHARFROMPOS and EM_POSFROMCHAR are used in many places, e. g. for drag'n'drop support, and there isn't an alternative to these messages.