×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Dropdown won't select with mouse, only keyboard

Dropdown won't select with mouse, only keyboard

Dropdown won't select with mouse, only keyboard

(OP)
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

RE: Dropdown won't select with mouse, only keyboard

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

RE: Dropdown won't select with mouse, only keyboard

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

RE: Dropdown won't select with mouse, only keyboard

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

RE: Dropdown won't select with mouse, only keyboard

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 Smileing

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

RE: Dropdown won't select with mouse, only keyboard

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

RE: Dropdown won't select with mouse, only keyboard

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 Smileing

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

RE: Dropdown won't select with mouse, only keyboard

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

What's still an open end:

Quote (foxmuldr3)

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

RE: Dropdown won't select with mouse, only keyboard

(OP)
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

RE: Dropdown won't select with mouse, only keyboard

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

RE: Dropdown won't select with mouse, only keyboard

(OP)

CODE --> VFP9

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

RE: Dropdown won't select with mouse, only keyboard

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.

CODE

#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

RE: Dropdown won't select with mouse, only keyboard

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

RE: Dropdown won't select with mouse, only keyboard

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

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

RE: Dropdown won't select with mouse, only keyboard

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

RE: Dropdown won't select with mouse, only keyboard

(OP)
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

RE: Dropdown won't select with mouse, only keyboard

I said:

Quote (myself)

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

RE: Dropdown won't select with mouse, only keyboard

(OP)
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

RE: Dropdown won't select with mouse, only keyboard

Quote (foxmuldr3)

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

RE: Dropdown won't select with mouse, only keyboard

(OP)

Quote (Chris Miller)

You confuse me with your responses.

My wife tells me I have special powers in that regard. LOL smile 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

RE: Dropdown won't select with mouse, only keyboard

(OP)
I wrote the C++ program below, and here are the results when I open a dropdown in Windows. It produced the following output when the dropdown opens up:

CODE --> Output

* Dropdown is opened with mouse click:
#1 -- New window for popup
Add 002e0e88 <no title>
X=56, Y=122, W=560, H=53
Class = vfp994000003
[caption][popup][child][disabled][clipsiblings][caption][border][dlgframe][sysmenu][thickframe][sizebox][tiledwindow]
  Parent = 00080a5a Microsoft Visual FoxPro

#2 -- Shadow
Add 00930a26 <no title>
X=56, Y=122, W=565, H=58
Class = SysShadow
[overlapped]

* Dropdown is closed by losing focus:
#1 -- Delete shadow
Del 00930a26 <no title>

* Dropdown is again opened by mouse click:
#1 -- Delete prior popup
Del 002e0e88 <no title>

#2 -- Add new window just as an overlapped window though
Add 002f0e88 <no title>
X=56, Y=122, W=560, H=53
Class = vfp994000003
[overlapped]
  Parent = 00080a5a Microsoft Visual FoxPro

#3 -- Add shadow
Add 002609de <no title>
X=56, Y=122, W=565, H=58
Class = SysShadow
[overlapped]

* Dropdown is closed by losing focus:
Del 002609de <no title> 

Here is the source code to replicate what I did. Compiled in Visual Studio as an x86 (32-bit) project (due to use of GWL_HINSTANCE).

CODE --> 2022

// GlobalWindows.cpp

#include <windows.h>
#include <list>

struct SHwnd
{
    bool    lDeleted;
    bool    lChanged;
    bool    lNew;
    bool    lDisplayed;

    union
    {
        HWND    hwnd;
        int     _hwnd;
    };
};

std::list<SHwnd*>     hwnds;

bool iiLookupHwnd(HWND hwnd)
{
    SHwnd*                          h;
    std::list<SHwnd*>::iterator     hi;


    // Iterate through the list
    for (hi = hwnds.begin(); hi != hwnds.end(); ++hi)
    {
        // Grab the structure
        h = *hi;

        if (h->hwnd == hwnd)
        {
            // This one matches
            h->lChanged = false;
            return true;
        }
    }

    // If we get here, not found
    return false;
}

void iiAppendHwnd(HWND hwnd)
{
    SHwnd*      h;


    // Create it
    h             = new SHwnd;
    h->hwnd       = hwnd;
    h->lChanged   = true;
    h->lNew       = true;
    h->lDeleted   = false;
    h->lDisplayed = false;

    // Add to the list
    hwnds.push_back(h);
}

BOOL CALLBACK EnumChildWindowsProc(HWND hwnd, LPARAM l)
{
    // Store the window
    if (!iiLookupHwnd(hwnd))
        iiAppendHwnd(hwnd);

    EnumChildWindows(hwnd, EnumChildWindowsProc, NULL);
    return TRUE;
}

BOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM l)
{
    // Store the window
    if (!iiLookupHwnd(hwnd))
        iiAppendHwnd(hwnd);

    EnumChildWindows(hwnd, EnumChildWindowsProc, NULL);
    return TRUE;
}

int main()
{
    bool        llFirst;
    RECT        lrc;
    wchar_t     title[1024];
    WNDCLASSW   wc;

    SHwnd*                          h;
    std::list<SHwnd*>::iterator     hi;

    union
    {
        HWND    hwndP;
        int     _hwndP;
    };


    // Enter a loop to repeatedly show differences
    llFirst = true;
    while (true)
    {
        // Mark everything changed, which means if it exists now and it's still marked changed at the end, then it's been deleted
        for (hi = hwnds.begin(); hi != hwnds.end(); ++hi)
            (*hi)->lChanged = true;

        // Get all windows, and child windows, and child-of-child windows...
        EnumWindows(EnumWindowsProc, NULL);

        // Report differences
        if (!llFirst)
        {
            // Display any changes
            for (hi = hwnds.begin(); hi != hwnds.end(); ++hi)
            {
                h = *hi;
                if (h->lChanged && (IsWindowVisible(h->hwnd) || h->lDisplayed))
                {
                    // Get the window title/caption
                    h->lDisplayed = true;
                    GetWindowText(h->hwnd, title, sizeof(title) / sizeof(title[0]));

                    // Display the event
                    h->lDeleted = (!h->lNew && h->lChanged);
                    if (h->lDeleted)
                    {
                        // Window has been deleted
                        wprintf(L"%s %08x %s\n", L"\nDel", h->_hwnd, ((title[0] == 0) ? L"<no title>" : title));

                    } else {
                        // New window
                        wprintf(L"%s %08x %s\n", L"\nAdd", h->_hwnd, ((title[0] == 0) ? L"<no title>" : title));
                        GetWindowRect(h->hwnd, &lrc);
                        wprintf(L"X=%d, Y=%d, W=%d, H=%d\n", lrc.left, lrc.top, lrc.right - lrc.left, lrc.bottom - lrc.top);
                        GetWindowLong(h->hwnd, GWL_HINSTANCE);
                        GetClassName(h->hwnd, title, sizeof(title) / sizeof(title[0]));
                        GetClassInfo((HINSTANCE)GetWindowLong(h->hwnd, GWL_HINSTANCE), title, &wc);
                        wprintf(L"Class = %s\n", title);

                        if (wc.style & WS_CAPTION)          wprintf(L"[caption]");
                        if (wc.style == WS_OVERLAPPED)      wprintf(L"[overlapped]");
                        if (wc.style & WS_POPUP)            wprintf(L"[popup]");
                        if (wc.style & WS_CHILD)            wprintf(L"[child]");
                        if (wc.style & WS_MINIMIZE)         wprintf(L"[minimize]");
                        if (wc.style & WS_VISIBLE)          wprintf(L"[visible]");
                        if (wc.style & WS_DISABLED)         wprintf(L"[disabled]");
                        if (wc.style & WS_CLIPSIBLINGS)     wprintf(L"[clipsiblings]");
                        if (wc.style & WS_CLIPCHILDREN)     wprintf(L"[clipchildren]");
                        if (wc.style & WS_MAXIMIZE)         wprintf(L"[maximize]");
                        if (wc.style & WS_CAPTION)          wprintf(L"[caption]");
                        if (wc.style & WS_BORDER)           wprintf(L"[border]");
                        if (wc.style & WS_DLGFRAME)         wprintf(L"[dlgframe]");
                        if (wc.style & WS_VSCROLL)          wprintf(L"[vscroll]");
                        if (wc.style & WS_HSCROLL)          wprintf(L"[hscroll]");
                        if (wc.style & WS_SYSMENU)          wprintf(L"[sysmenu]");
                        if (wc.style & WS_THICKFRAME)       wprintf(L"[thickframe]");
                        if (wc.style & WS_MINIMIZEBOX)      wprintf(L"[minimizebox]");
                        if (wc.style & WS_MAXIMIZEBOX)      wprintf(L"[maximizebox]");
                        if (wc.style & WS_TILED)            wprintf(L"[tiled]");
                        if (wc.style & WS_ICONIC)           wprintf(L"[iconic]");
                        if (wc.style & WS_SIZEBOX)          wprintf(L"[sizebox]");
                        if (wc.style & WS_TILEDWINDOW)      wprintf(L"[tiledwindow]");
                        wprintf(L"\n");

                        hwndP = (HWND)GetWindowLong(h->hwnd, GWL_HWNDPARENT);
                        while (hwndP != NULL)
                        {
                            GetWindowText(hwndP, title, sizeof(title) / sizeof(title[0]));
                            wprintf(L"  Parent = %08x %s\n", _hwndP, ((title[0] == 0) ? L"<no title>" : title));
                            hwndP = (HWND)GetWindowLong(hwndP, GWL_HWNDPARENT);
                        }
                    }

                    // Lower the new flag
                    h->lNew = false;
                }
            }
        }
        llFirst = false;

        // Remove all the deleted ones
        std::list<SHwnd*>::reverse_iterator hir;
        for (hir = hwnds.rbegin(); hir != hwnds.rend(); ++hir)
        {
            h = *hir;
            if (h->lDeleted)
            {
                hwnds.remove(h);
                free(h);
            }
        }
    }
} 

--
Rick C. Hodgin

RE: Dropdown won't select with mouse, only keyboard

Good, in parallel I extended the EnumWindows usage and can confirm that opening a combobox does raise the count by 1 and closing it lowers it again...

CODE

#INCLUDE vfp2c.h

Clear
Set Library To vfp2c32.fll Additive

Public goLogging, goTimer
goLogging = Createobject("Logging")
goTimer = CreateObject("WindowsTimer")

Activate Screen
? 'Initial count'
goTimer.CountNow()

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

Activate Screen
? 'Form started'
goTimer.CountNow()

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

Activate Screen
? 'combobox added'
goTimer.CountNow()
Keyboard '{Alt+DNARROW}'
? 'dropdown expanded'
goTimer.CountNow()
? 'any change monitored every 10ms'

On Key Label CTRL+F5 Clear Events
Activate Screen
? 'CTRL+F5 to exit'
Read Events
goTimer = .null.
goLogging = .null.
Release All LIKE go*

Define Class WindowsTimer As Timer
   Interval = 10
   
   Procedure Timer()
      Local loParents, loChildren
      loChildren = Createobject('WNDENUMPROC')
      loParents  = Createobject('WNDENUMPROC',loChildren)

      Declare Integer EnumWindows In user32.Dll Integer, Integer
      Declare Integer EnumChildWindows In user32.Dll Integer, Integer, Integer

      EnumWindows(loParents.Address,0)
      loParents = .Null.
      loChildren= .Null.
   EndProc
   
   Procedure CountNow()
       This.Timer()
   EndProc
Enddefine

Define Class Logging As Session
   LastCount = 0

   Procedure Log(tnCount)
      If This.LastCount != tnCount
         This.LastCount  = tnCount
         Activate Screen
         ? Seconds(), tnCount
      Endif
   Endproc
Enddefine

Define Class WNDENUMPROC As Exception
   Address = 0
   nCount = 0
   oChildren = .Null.

   Function Init(toChildren)
      If Pcount()=1
         This.oChildren = toChildren
      Endif
      This.Address = CreateCallbackFunc('EnumWindowsCallback','BOOL','LONG, LONG',This)
   Endfunc

   Function Destroy
      If This.Address != 0
         DestroyCallbackFunc(This.Address)
      Endif
      If Not Isnull(This.oChildren)
         goLogging.Log(This.nCount)
      Endif
   Endfunc

   Function EnumWindowsCallback(hHwnd,Lparam)
      This.nCount = This.nCount + 1
      If Not Isnull(This.oChildren)
         EnumChildWindows(hHwnd,This.oChildren.Address,0)
         This.nCount = This.nCount + This.oChildren.nCount
         This.oChildren.nCount = 0
      Endif
      Return .T.
   Endfunc
Enddefine 

Now that we settled that, I still don't know why the list sometimes is mouse sensitive and sometimes not. In my reproducible scenario there's nothing in front of the dropdown list that would block off mouse events.

What is true is that even though the dropdown list is now identified to have its own hwnd it's not necessarily on top, a transparent container will block off mouse events, for example, but in the scenario it's not the reason.

I wanted to add the identification of the new hwnd and its associated rectangle, but that also won't contribute to why it does not react to mousemove/mousover events and in short the dropdown list is not usable with a mouse.

Chriss

RE: Dropdown won't select with mouse, only keyboard

(OP)
Since the HWND of the popup is receiving mouse input, it has to send messages back to the parent HWND for VFP to identify the activity. I'm guessing the base number it's using is not being set properly for some reason, and the messages from the mouse are being sent back, but they're not being interpreted by the parent, so they're essentially being ignored.

The customer has also stated that "sometimes it works," which lends credence to that theory, in that there may be a race condition that's allocating for a message base range to send back on, and it's sometimes getting it, sometimes not.

If so, there's no fix for this other than possibly to force an affinity to a single CPU for the VFP app. I might try that.

--
Rick C. Hodgin

RE: Dropdown won't select with mouse, only keyboard

(OP)
Setting affinity did not work. Same issue as before.

--
Rick C. Hodgin

RE: Dropdown won't select with mouse, only keyboard

Another wild guess. Since the new Dell computers seem to be very fast, could it be a timing issue somewere, either in the control or in the way it’s getting created on the form.

I remember many many moons ago we had a problem with FPW 2.6 on high speed CPU’s. Luckily the fpw2600.esl runtime file got fixed, I think in 2000 or 2001.

Regards, Gerrit

RE: Dropdown won't select with mouse, only keyboard

Is it something in front of the combobox, transparent, invisible, but still blocking?

For example, a container does block mouse usage of a combobox:

CODE

Clear

Local loForm
loForm = Createobject("form")
loForm.Show()

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

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

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

*add container in front of combobox (later added objects are in front of previously added)
loForm.AddObject("container1","container")
loForm.container1.width=loForm.width
loForm.container1.height=loForm.height
loForm.container1.backstyle= 0
loForm.container1.visible = .t.

Keyboard '{ALT+DNARROW}' 

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

As Griff said (a long time ago in a galaxy far far away), the form might not be designed intentionally to have something in front of controls that should be usable, but faulty resizing of form controls might cause that.

Besides that possible reason it won't explain scenarios that sometimes work, sometimes not, but it shows that even though the dropdown list window hwnd is created last at runtime, VFP respects the transparent container in front of the list blocking mouse events from it, the events only arrive at the container object, which you can see when you program a container with click code, mouseenter, mousemove, mouseleave, etc.

In short, if a control is in front of others, that blocks off mouse events to the controls behind it, no matter if the objects in front are transparent or not.

Chriss

RE: Dropdown won't select with mouse, only keyboard

(OP)
I'm going to write an extension to a utility DLL I have that will hook into the WndProc() functions used for both windows, intercepting every message. I'm going to compare the messages sent from a system that's working (my PC), and the ones that aren't working, to see if I can see where there's a message discrepancy.

--
Rick C. Hodgin

RE: Dropdown won't select with mouse, only keyboard

Well, that should help. Before I'd do that, you could of course rule out resizing problems, if it's all your code and you know it inside out anyway, then we'd also not need to guess into that direction. Anything else would be a bug, and I don't think there's a mouse events related bug in VFP9, that would be found very very late. Then I'd rather bet on driver issue, again.

There is one more thing that could happen with anything in VFP that's usually working: A change of Windows could cause VFP to not work properly, because VFP is out of even extended support and not taken into account when Windows changes are made and tested against the codebase of all currently supported MS products to not break them. But that's a cause I'd put into the least probable category the type of conspiracy theories.

Drivers, I remember Dell was nototriously known for driver issues. They got better and so eventually that suspicion about Dell computers having driver issues was dropped, but I wouldn't be surprised, when it turns out the mouse drivers don't feed the Windows event queue correctly, however that would cause trouble only in some controls and not others.

Just a tip about resizing problems of controls moving in front of others: Anchoring is hard to imagine how it effects this, because there's absolute and relative anchroing, anchroing to form border or container border and more. And there's no code involved to cause trouble, just the anchor property setting. Besides, it even sometimes still surprises me by which base (anchor) position anchoring works, when you set control positions and sizes before changing the Anchor property from 0 to some anchroing behavior. In short: It's complicated. And it's easy to achieve some not intended overlap of controls by anchoring.

Chriss

RE: Dropdown won't select with mouse, only keyboard

(OP)
Chris, I think you and I would do well collaborating on projects together.

Ever want to work on Visual FreePro?

--
Rick C. Hodgin

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close