lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master 3c3454d6 5/5: Allow GUI test to fail


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master 3c3454d6 5/5: Allow GUI test to fail
Date: Sun, 4 Sep 2022 01:38:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

On 9/3/22 22:14, Vadim Zeitlin wrote:
> On Sat, 3 Sep 2022 21:39:18 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> [...]
> GC> The only hypothesis that occurs to me is that we're trying to simulate
> GC> a click at a point outside the screen dimensions. But no--I added this
> GC> code (changing my "#if 0" to "#if 1", and including <iostream>):
> GC> 
> GC>      // by clicking somewhere inside the control.
> GC> +    std::cout
> GC> +        << "10*W " << 10 * grid_window->GetCharWidth()
> GC> +        << " 3*H " <<  3 * grid_window->GetCharHeight()
> GC> +        << std::endl
> GC> +        ;
> GC>      ui.MouseMove
> GC> 
> GC> and it said:
> GC> 
> GC>   10*W 140 3*H 75
> GC>   paste_census: ERROR (Assertion failure: Expected class defaults dialog 
> was not shown. [file /
> GC>   opt/lmi/src/lmi/wx_test_paste_census.cpp, line 324, in run()].)
> GC> 
> GC> That's a different "ERROR" message than before, but the goal of
> GC> this new test was to see where the point lies, and [140W, 75H]
> GC> would be on the screen even with an ancient CGA monitor. (This
> GC> isn't a very good test because I didn't pass that point through
> GC> ClientToScreen(), but I suspect this is enough information to
> GC> dismiss my hypothesis above.)
> 
>  The problem is that I don't have any other ones, so I wonder if there is
> something wrong with ClientToScreen() in this configuration somehow.
> 
> GC> > I also have no idea why am I not seeing the problem, as I'm using the
> GC> > official lmi build system in a chroot dedicated to it, and, worse,
> GC> > don't really know how to debug this further without your help and I'm
> GC> > not sure if it's worth wasting your time on this.
> GC> 
> GC> I'm willing to run tests if you're willing to guess at
> GC> corrections that might work. So far, this is working well.
> 
>  I can't really guess at correction, my only idea is to print the value
> returned by ClientToScreen() and, maybe, dump the window at this position,
> i.e.
> 
>       std::cout << wxDumpWindow(wxFindWindowAtPoint(...)).utf8_string();
> 
> where "..." stands for the point returned by ClientToScreen().

I tried:

    std::cout
        << "10*W " << 10 * grid_window->GetCharWidth()
        << " 3*H " <<  3 * grid_window->GetCharHeight()
        << std::endl
        ;
    std::cout << "dump window: " << wxDumpWindow(wxFindWindowAtPoint
        (ClientToScreen
            (wxPoint
                (10 * grid_window->GetCharWidth()
                , 3 * grid_window->GetCharHeight()
                )
            )
        )
                             ).utf8_string();

but that doesn't compile:
  error: cannot convert ‘wxPoint’ to ‘HWND’ {aka ‘HWND__*’}
However, this is the problem that we've already solved, or at least
sidestepped, so I don't think we should spend more time on it.

> GC> Do you have any idea for fixing the other problem, i.e.:
> GC> 
> GC>   validate_output_census: started
> GC>   validate_output_census: ERROR (Assertion '0 <= row && row < 
> grid_table_->GetRowsCount()' failed. [census_view.cpp : 1144] )
> GC> 
> GC> ?
> 
>  Sorry, I hoped it was somehow caused by the first one, but thinking more
> about it now I realize that this couldn't have been the case as they happen
> in different tests. Both problems are probably caused by the same
> underlying bug, but it doesn't really help us to find what it is. Something
> seems to prevent the grid from having any selection, but I just don't see
> what could it be.

Yes, and how could that plausibly depend on DPI?

> GC> I've determined that that error message arises here, in
> GC> init_test_census() in file 'wx_test_validate_output.cpp':
> GC> 
> GC>     ui.Char('e', wxMOD_CONTROL); // "Census|Edit cell"
> GC>     std::cout << "line " << __LINE__ << std::endl;
> GC>     // I added the __LINE__ line above, and it prints correctly.
> GC>     wxTEST_DIALOG
> GC>         (wxYield()
> GC>         ,change_name_in_cell_dialog(insured_name)
> GC>         );
> GC>     // The following added line does not print:
> GC>     std::cout << "line " << __LINE__ << std::endl;
> GC> 
> GC> Even when I backed up to the function that invokes this:
> GC>   LMI_WX_TEST_CASE(validate_output_census)
> GC> I didn't see an obvious place to add a line like
> GC>   grid_window->SelectRow(0);
> GC> which would presumably fix that "ERROR".
> 
>  We'd have to factor out find_census_grid_window() function from the paste
> census test and reuse it here to get access to this window. But it actually
> looks like this test might be showing an actual problem with lmi (under
> Wine only, but still), i.e. don't you see the same assert when pressing
> Ctrl-E interactively?

No, absolutely not, never.

Flailing, I tried changing
  wxWindow* CensusView::CreateChildWindow()
thus:

+    grid_window_->SelectRow(0);
     return grid_window_;
 }

but got:

validate_output_census: ERROR (Assertion failure: Expected census cell dialog 
was not shown. 
[file /opt/lmi/src/lmi/wx_test_validate_output.cpp, line 194, in 
init_test_census()].)

>  Sorry for lack of help, but I just don't have any ideas at all, let alone
> good ones.

Then the answer is to leave DPI at 96. For any serious work
that requires using lmi's GUI, I'll choose a GTK build.
If I ever must use msw, either I'll change DPI beforehand
and change it back after, or I'll just navigate by sense
of smell.

Debugging wine weirdness in a frame buffer is too onerous.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]