Dropdown won't select with mouse, only keyboard

[foxmuldr3]

Haven't seen this before. We have a customer that purchased three new 24-CPU Dell machines with Windows 11. The FoxPro apps we have don't allow the combobox dropdowns to work without using the keyboard. You can click on the control to bring up the dropdown list, and then arrow up/down and press Enter to choose something, but it won't interact with the mouse other than to close the dropdown when you click on any item or the scrollbar.

Has anyone seen this before?

I did notice on these machines that when we ran our installer, it did not install MSCOMCTL.OCX and MSCOMCT2.OCX automatically. We had to go in behind and install/register them manually. I'm assuming it's something similar with the underlying dropdown control, since other dropdowns work (in Excel, for example, to choose a font size).

--
Rick C. Hodgin

 

[Chris Miller]

I assume the cotrol you talk about is the combobox?

Not that it helps me knowing this, though. Sorry, I don't know anything within VFP that would disallow mouse interaction with the dropdown list, i.e. mose moving causes highlighting the item under the mouse and clicking it then selects it. If that doesn't work I'd look into mouse drivers.

Chriss

 

[Mike Lewis]

I was also going to suggest that you check your mouse driver. But the fact that it works in Excel would seem to point away from that. And presumably you haven't seen any other mouse-related problems?

When I see weird behaviour like this in comboboxes (and certain other controls), I try fiddling with the SpecialEffect and/or Themes properties. But that's probably a long shot in this case.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I just know some people here, don't remember who, had problems especially with mousewheel and scrolling and installing a correct driver instead of the MS generic mouse drivers solved these issues. It smells very much like a drivers issue to me, something that's also very probable, an admin sets up a new computer, plugs in a mouse, it instantly works and you never care about installing a proper mouse driver and keep the generic MS driver.

PS: On my current PC I have used two mice, nothing special, and the device manager shows two drivers, both "HID-compliant mouse" MS drivers. I just think a mouse with some specialties also needs its special drivers, if you have a generic mouse - and mine also has a mouse wheel with double wheel/button functionality, the MS drivers are sufficient and work, I'm not saying the MS drivers are causing this, it would be the combination with this unspecific driver and a mouse that needs a bit more specific driver that could cause partial misfunctioning.

Chriss

 

[GriffMG]

There isn't a visual element in front of it is there, perhaps you can tab to the control, but there is something
obscuring it from the mouse? Behind a page frame or box or somethig?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Chris Miller]

Griff,

I had this idea, too, but it's an application that worked before the change of the computer. The only chance the reason is within VFP, including that problem of a transparent blocking container or other control is, that they installed another (older or newer) version of the software on the new computer.

Chriss

 

[GriffMG]

I can think of a couple of situations where the position of a control or visual element might change with a given workstation.

a) If some of the elements were positioned by the user or someone and that position was stored locally - in a configuration file.

b) If the position of some elements depended on screen size/resolution - perhaps calculated as being x or y distance from one side
or the top of the screen.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Chris Miller]

Okay, that's another good point: Screen resolution change.

What's still an open end:

We had to go in behind and install/register them manually. I'm assuming it's something similar with the underlying dropdown control

I asked, whether it is the combobox, but why would Rick then talk about "underlying dropdown control".

So Rick, is it another ActiveX or what is it?

Chriss

 

[foxmuldr3]

The combobox dropdowns are the part that comes down (or goes up) once you click the down arrow on a combobox. That popup part uses a separate HWND that is its own window to Windows, and it's not drawn atop the existing form window.

I believe the issue is there in the handler for that popup, and it is likely a related issue to the configuration of those machines since they have three identical machines all with the same issue, and we don't see it with any of our other installations.

--
Rick C. Hodgin

 

[Chris Miller]

Foxpro controls don't have their own HWND, only ActiveX controls do.

So you are talking of an ActiveX control? Or do you talk of the VFP combobox?


Chriss

 

[foxmuldr3]

MODIFY FORM c:\temp\test.scx
* Add a single combobox.
* Add this code for Load():
CREATE CURSOR c_data ;
( ;
    cItem      c(120) ;
)

INSERT INTO c_data VALUES ("Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1")
INSERT INTO c_data VALUES ("Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2")
INSERT INTO c_data VALUES ("Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3")

* Non-default properties:
* RowSource = c_data
* RowSourceType = 2 - Alias

Un-maximize your VFP9 window and make it about 2/3rds the size of your desktop, aligned with the left edge. Ctrl+E to run the form. Position the form near the right-edge, and expand open the dropdown. You'll see it pop up like the attached image.

--
Rick C Hodgin

 

[Chris Miller]

The overlap does not prove anything.
I think you still have vfp2c32.fll, don't you? From the thread where you added/extended the AdirEx() function.

Then you should be able to get this running. It needs the vfp2c32.fll and accompanying files and you should CD into the directory with the FLL, of course.

#INCLUDE vfp2c.h

Clear
Set Library To vfp2c32.fll Additive

CountAllWindows()

Local loForm
loForm = Createobject("form")
loForm.Left=200
loForm.Show()
CountAllWindows()

Create Cursor c_data ;
   ( ;
   cItem      c(120) ;
   )

Insert Into c_data Values ("Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1 Item 1")
Insert Into c_data Values ("Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2 Item 2")
Insert Into c_data Values ("Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3 Item 3")

loForm.AddObject("combobox1","combobox")
With loForm.combobox1
   .RowSource = "c_data"
   .RowSourceType = 2
   .Visible=.T.
Endwith

CountAllWindows()
Keyboard '{Alt+DNARROW}'
CountAllWindows()

On Key Label CTRL+F5 Clear Events
? 'CTRL+F5 to exit'
Read Events

Procedure CountAllWindows()

Local loCallback
loCallback = Createobject('WNDENUMPROC')
Declare Integer EnumChildWindows In user32.Dll Integer, Integer, Integer
EnumChildWindows(_vfp.hwnd,loCallback.Address,0)
nStart = Seconds()
Do while Seconds()-nStart<.1
   Doevents 
EndDo 
loCallback = .null.

Define Class WNDENUMPROC As Exception
   Address = 0
   nCount=0

   Function Init
      This.Address = CreateCallbackFunc('EnumWindowsCallback','BOOL','LONG, LONG',This)
   Endfunc

   Function Destroy
      Activate Screen
      ? This.nCount
      If This.Address != 0
         DestroyCallbackFunc(This.Address)
      Endif
   Endfunc

   Function EnumWindowsCallback(hHwnd,Lparam)
      This.nCount = This.nCount + 1
      Return .T.
   Endfunc
Enddefine

I'm open to be corrected, but you'll see generating the loForm creates a new hwnd, creating a combobox on it not, dropping down the list neither.
You can draw on the desktop, whatever VFP does, it does not introduce a new HWND for the list as far as I can see from this.

I'm counting all child windows of _Vfp.hwnd, you could also start at the Desktop hwnd, when you won't count child windows of applications, though. The only possibility for another hwnd is somewhere burried in some other hwnd not exposed and still belonging to VFP, but I don't see the benefit, it should be a child of the desktop, as it can in circumstances stick out of _screen. too. But the desktop child window count stays constant for me, even when a new form is clearly creating a new hwnd.

Anyway, I think VFP just draws directly on the desktop and that always was a reason VFP applications slip through the control of automation tools, WinSpector, Spy++ and the like, that require controls to have their own HWND. All VFP controls are not their own Windows including dropdown parts of them.

Chriss

 

[Chris Miller]

There's something else that I observe with my example of using Keyboard '{Alt+DNARROW}' to programmatically drop down the list: The list does not react to mouse hovering. When you collapse and reopen it, the hovering works. The first time it reproducible does not react to hovering. At least for me. Also if you remove all calls of CountAllWindows() and the SET LIBRARY, etc., so there is a problem of dropdown lists sometimes not reacting to hovering.

Chriss

 

[foxmuldr3]

I will write some code to correct either you or me when I get the chance.

If you want, try writing an app to test for top-level WS_CHILD or tool windows present in the system (all of them). Make it run continually and report changes. When the dropdown opens up you'll see a new entry, and when it collapses you'll see it go away.

I think you'll find it's not a child of the form, but is its own top-level input, probably a tool window associated with another thread entirely (meaning its WndProc address will be different) is my guess. And I think that's where the disconnect is happening. Whatever engine is displaying the popup is not receiving or processing mouse input properly, hence the disconnect.

--
Rick C. Hodgin

 

[Chris Miller]

EnumWindows, according to documentation, list all child windows of a parent, not only direct children. And _vfp.hwnd is the parent of all windows of a VFP9.exe process.

It would indeed be interesting to get a complete list of all windows, EnumWindows skips some system windows, again, according to documentation, but I doubt that's hinderig to see a control or dropdown hwnd.

We'll see.

Aside from that, I can reproduce what you and your customers experience, as said, the dropdown as created in my example doesn't react to mouse movements on it, at least on my computer - reproducible everytime, so I gues this could be used to investigate what happens with mouse events, for example with notifications like WM_MOUSEMOVE.

Chriss

 

[foxmuldr3]

Are you saying you cannot click on any time in the dropdown, and that it doesn't track with the mouse moving as it goes? And that you can only access it by keyboard?

We have not been able to reproduce that condition, but that is what our client is seeing on three new 24-core Dell PCs.

--
Rick C. Hodgin

 

[Chris Miller]

I said:

There's something else that I observe with my example of using Keyboard '{Alt+DNARROW}' to programmatically drop down the list: The list does not react to mouse hovering. When you collapse and reopen it, the hovering works. The first time it reproducible does not react to hovering.

You may replace hovering with moving, i.e. when I move the mouse over the dropdown list as it is created by my example with Keyboard '{Alt+DNARROW}', no item is highlighted. Only when I collapse the list and reopen it it reacts to the mouse.

To be more precise: The first item is highlighted and remains highlighted, no matter where I move the mouse.

Anyway, reopening the list it works, it's not a permanent issue everytime with this dropdown list. But I can also reproduce it when I copllapse the list and manally open it by using ALT+DNARROW not in code, just actually doing it instead of clicking on the drop down button. If this is by design it would mean VFP assumes opening the list by keyboard you'll also pick an item with keys, when you open the list by mouse click the mouse also picks the item.

One more thing: Even when the highlighting by mouse moves does not work, clicking on an item pcks it.

Chriss

 

[foxmuldr3]

All of the comboboxes we have can be clicked on or use the keyboard to open, and they all work with the mouse ... except these three identical computers.

I haven't had time to spend on the issue yet, so I'm pulling all of my details from memory. IIRC, the dropdown used a popup window similar to the IME input. It's above everything, but it will immediately close itself when it loses focus. Your full window and child window scanning app will have to run continuously in the background and note changes into an editbox or something. thisForm.edit1.value = TTOC() + " " + lcNewChange + CHR(13) + thisForm.edit1.value repeatedly for each change. That way you'll see them.

--
Rick C. Hodgin

 

[Chris Miller]

IIRC, the dropdown used a popup window similar to the IME input. It's above everything, but it will immediately close itself when it loses focus.

Well, that's not how a native VFP combobox works, the dropdown list only collapses if you do one of two things:
1. pick an item
2. click outside of it.
And
3. It stays open when the mouse leaves the list.

I'm not sure, but it sounds like you describe something else than a VFP combobox, though I thought we had cleared that question with your sample code for the items of a clearly, simple normal VFP combobox.

IME is something I only know of Japanese Windows, I never worked with such things, neither on the basis of VFP nor in any other way. But do we actually talk of Chines or Japanese or other language Windows systems that require IME inputs?`

I begin to wonder if we talk VFP here at all!? You confuse me with your responses.

I call Enumeration directly after I create the combobox and directly after I cause the dropdown list to drop down. Anyway, you can change the experiment as needed, I'm still very sure not only from this experiment there is nothing based on further hwnds in VFP controls.

Chriss

 

[foxmuldr3]

You confuse me with your responses.

My wife tells me I have special powers in that regard. LOL I just think about things differently than other people do at times. I look at most things from a lower-level perspective. For the combobox dropdown part, for example, I recognize it as a separate window being drawn by Windows. I understand the internal message system that Windows uses, and I'm primarily a C/C++/x86 assembly developer, so I see can't help but look at things from those lower-levels.

I will work on a global enum windows function here this afternoon and post my results.

--
Rick C. Hodgin