TOPIC:

I've seen this recently as well, as far as I know for the first time and now I got it again. I have a DataDialog with a comboboxEx on it. I wanted it to drop down on opening the window for which I already created some code which I didn't immediately realize. Anyhow, I found this line and put it in the PostInit:

What happens is that the content which should be displayed within the dropped down combobox displays as a kind of ghost image in the upper left corner of my main screen. See image, I added SomeName twice for this picture and put the real window next to the "ghost content' but if the real window opens in another monitor the 'ghost' window is still in the main monitor. As soon as I click somewhere in the screen, or issue a Setfocus or something, the "ghost window" disappears (and the window with the combobox opens normally.



What could cause this?

Dick

No idea - but isolate the window with the dialog in a new app and if the problem reproduces, send it to Chris.

Hi Dick

I can't be sure, but it looks to me as though, by putting that line in the PostInit you have shifted the display co-ordinates.

My reason for saying this is that the x,y co-ordinates relate to your screen (in pixels). What you see on screen
will always be related to the
Top Left screen co-ordinates, (0,0).

By including that line in the PostInit you are adding the combo box, then telling the DataDialog to manifest itself
1 unit right of 0, and 0 down. (The unit is probably pixels. Can't be sure about this, but in any event it is NOT 0,0 where it should be.

So the problem is not showing a ghost, but not overwriting the entirety of a control.

I hope this makes some sense. I know it's a bit of a brain teaser.

You could just check if what I am saying is correct by changing the line to:
SendMessage(SELF:oDCcBox:Handle(),CB_SHOOWDROPDOWN, 0, 0L)

Terry

Hello Karl, Terry,

Thanks for your replies. I first tried to change wParam of SendMessage from 1 to 0. This resulted in the combobox no longer expanding at all. And I think I have not much other choices than to put in the postinit (as written, I have another solution which works).

Then I added a DataDialog with a combobox to a simple test app and indeed, the ghost window appears there too.

I will send it to Chris to see if we can find the cause. I have the same issue in an X# solution where I show a WebView2 in a Custom control so if Chris can find out what happens it will probably solve that issue too.

Dick

Hi Dick

Maybe it's the order in which you are doing things. If your Combo-Box is meant to show on the Dialog Window, you must add it after.

Terry

ic2 wrote: ...And I think I have not much other choices than to put in the postinit..

FTR, as there's no guarantee what may happen between a Postinit and the final Show i used to add such things in my Show().

Hi Dick

I am a bit puzzled as to why you do things this way. If the control is intended to be on the Dialog it should be initialised within the window itself. i.e its Init method. Correct ordering follow automatically and the offending line would not be required.
Maybe I'm misunderstanding something.

Terry

Hello Terry, Karl,

I emphasize that I later found a solution created earlier which actually works. So getting it to work is not the real issue.

I am however puzzled while this line of code has such a weird effect, as I found this in the comp.lang NG as a way to just auto-expand the combobox. The way I see it is that the comobox is already initialized in the init and hence the SendMessage should do just that job when issues in the postinit. I also wonder what actually happens as the system is painting outside the control and I have another such situation in a completely different situation in an X# program.

As this is probably easy to follow for an expert like Chris, I sent him that basic sample and I will certainly report back his findings. And hopefully it helps me solve the X# issue as well.

Dick

Have you tried increasing the width? See what happens.
Terry

Hi Dick,

Nobody is more of an expert in this area than Karl-Heinz!

I agree with what the other guys said, it's a problem of trying to drop down the combo box, before it is shown.and windows receives a message at a time it does not expect it to, and gives this weird, semi-random behavior. I think this specific behavior has to do with the implementation details of the control, as I assume the drop down part of the combobox is implemented as a separate window which is disaplayed by windows on top of the owner window of the control, but then you try to show this before the owner window is shown and all hell breaks lose..

You definitely need to do this after the window is being shown, but not sure exactly when is the right time. Before looking further into it, you said you have already found a solution. Which is that?

.

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