xsharp.eu

Hello Chris,

There are 3 reasons why I am not sure about the control not being painted and 1 reason why it could make sense

1 because I use the now offending line in the postinit. I would say the control should have been painted in the init. I always have code in the postinit which assumes the control involved is available and this is the first time it doesn't work
2 because I have (by the way it looks) the same problem with the WebView2 content in X# and there the ghost window appears after I close the window containing the original content.
3 because when I follow Terry's suggestion to change the width, the width is changed. But the ghost window still appears. Why would the width assignment work 100% if the window/control is not shown but 1 line later the SendMessage causes a ghost window:
but

4 when I move the SendMessage to a button on the screen the ghost window stays away indeed.



The earlier working method: I let the combobox inherit from Ic2ComboBox featuring these 2 methods below


Dick

METHOD FocusChange( oEvent ) CLASS Ic2ComboBox
//#s Auto drop down combobox 17-2-2004
LOCAL lGotFocus AS LOGIC

SELF:lAutoDrop:=TRUE
lGotFocus := IIF( oEvent == NULL_OBJECT, FALSE, oEvent:GotFocus )
SUPER:FocusChange( oEvent )
IF lGotFocus
IF SELF:lAutoDrop // Drop down automatically each time control receives focus
PostMessage( SELF:Handle(), CB_SHOWDROPDOWN, 1, 0L )
ENDIF
ENDIF
RETURN NIL
METHOD Dispatch (oEvent) CLASS IC2ComboboxEx
LOCAL uretval AS USUAL
uRetval := SUPER:Dispatch(oEvent)
IF oEvent:message = WM_CHAR
SELF:Setvalue(CHR(oEvent:wparam))
ENDIF
RETURN uRetval

Hi Dick,

Specifying a new width is not a big deal, it's just some simple info sent to the control, telling it to use this width when it gets drawn. But nothing needs to happen at the time you send this message. But sending a message to drop down a portion of the control which is not visible yet is completely different, it forces the extra portion of the control to display at the moment you sent the message , while the control itself is not displayed.

Thanks for the code about FocusChange(), that's indeed the place where it's appropriate to send the message. Very soon after the control itself has been painted by windows.

.

Hi Dick

Sorry, when I suggested increasing the width, I did not mean width of the comboBox.

I meant width of the Ghost. This should be easy, simply increase the offset at which it is overwritten:

PostMessage( SELF:Handle(), CB_SHOWDROPDOWN, Increase, 0L ).

This number is likely to be pixels at 96 Dpi.

This probably won't cure the problem, but may give you a clearer insight into what is happening.

My guess is that your ghost will turn out to be more of a Red Herring.

Terry

Guys,

The "ghost" window you see is the Listbox control of the ComboBox. Using PostMessage() instead of Sendmessage() in the PostInit() positions the ListBox where it should be.


regards
Karl-Heinz
.

Hi Karl-Heinz,

Very nice, I did mention it that you're the expert!

I didn't think of it myself, but I guess it makes sense that PostMessage() works, because this puts the message in the message queue and it gets executed after all the previous necessary initialization messages have been processed. While SendMessage() asks windows to perform the action right now.

.

Hello Karl-Heinz, Terry,

Indeed PostMessage works.

It does not explain my X# issue however also showing a ghostwindow in the upper left corner, of a WebVIew2 (as customcontrol) after closing the window, so I hope to isolate that too in a sample.

@Chris, did you happen to read the X# Intellisense remark I made in the mail. I know it's no related but I got it while working on the WebView2 program and decided to mention it in the mail.

Dick

Hi Dick,

Sorry, indeed I had missed that, but I can reproduce it now. Will open a ticket about it for Robert to look into, thanks for reporting!

.

Dick

I suspect these things are related, although not directly.

The fact is there is one thing in the natural real world that is common with electricity in the underlying electronics, and that is neither can go backwards in time.

But programs require things to go both backward and forwards.

It follows that things have to "frigged" to make going backwards look like going forward.

The only way this can be done is to look forward to the end of program processing, then, still going forward, looking back into the earlier forward processing (which is now in the past).

Just the same as our telephone systems where we don't know where a call is from until it's reached its destination.

Just like the implementation of intellisense.

The only, but very significant difference between humans and electricity is that of speed. The latter, in free space, would travel at the speed of light. Constraining it to run along wires (eg the tracks on the mother board) slows processing, but it is still fast enough to fool us into thinking things are going backwards.

I have found that thinking this way helps both in implementing efficient code and seeing the solution to problems when they inevitably occur.

By the way the points about electrical flow can be scintifically proved.

Terry

Hello Terry,

I will probably have to dig into it when it doesn't work either on the system of Frank; this is where it is supposed to work and it does...

In that case I will try hard to find a relation, indeed the reason why I asked this "easier' issue here.

Everyone thanks for the input, to be continued...

Dick