Forum Discussion

mgy333's avatar
mgy333
Contributor
13 years ago

Refreshing screen using Win32API

We have a piece of code which draws green circle for pass and red x for fail on the screen.



I had a routine to clear those drawings, which worked flawlessly for a very long time, since TestComplete 3.



But when we upgraded from TestComplete 7 to TestComplete 8.6, that no longer worked.  It throws exception: An exception occurred: 0xC0000005; class: ; description: ''.



The code to clear the screen that no longer works:



            var User32DLL = DLL.DefineDLL("USER32");

            var User32Lib = DLL.Load("USER32");

            var oRect;

            var defRect = DLL.DefineType("RECT",

                                            vt_i4, "left",

                                            vt_i4, "top",

                                            vt_i4, "right",

                                            vt_i4, "bottom"

                                            );

           

            User32DLL.DefineProc("InvalidateRect", vt_i4, defRect, vt_i4, vt_bool);

           

            oRect = DLL.New("RECT");

            oRect.left = 0;

            oRect.top = 0;

            oRect.right = 0;

            oRect.bottom = 0;

           

            User32Lib.InvalidateRect(0, oRect, 0); // <---- TC8 throws exception





So I did some research and tried few different options.  None of the following works.  None of them cause any exceptions, but they don't seem to do anything either.



            Win32API.UpdateWindow(Win32API.GetDesktopWindow());

            Win32API.InvalidateRgn(0, Win32API.GetDesktopWindow(), true);

            Win32API.InvalidateRgn(0, Win32API.NULLREGION, true);

 

So is there a way to refresh the screen?  Why doesn't the above code no longer works with TC8?



Thanks,

Motoo

6 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    There was a bug at one point in time in TC 8 with the DLL interface to the USER32 dll.  We ran into problems with it using the SetAffinity method generating, essentially, the same error you received.



    There's a more recent version just released today, 8.70, that has some corrections for the DLL interface stuff.  I'd suggest installing and trying that.

  • Hi Motoo,





    I confirm Robert's suggestion - this is a known problem in version 8.60, and it is actually fixed in version 8.70.

    Please install the update, and check how it works for you.
  • Thanks for help.



    I installed the newest version, 8.7.  I was hopeful after your comments, but I didn't even get that far.



    I got the error at the line (on the code on the original post):



                var defRect = DLL.DefineType("RECT",

                                                vt_i4, "left",

                                                vt_i4, "top",

                                                vt_i4, "right",

                                                vt_i4, "bottom"

                                                );

     


    ...saying: A type with specified name is already defined



    Since it didn't even get to the line that was originally the problem, I cannot tell if the issue was fixed.



    Is there any ways to get around this?



    Thanks,

    Motoo

  • Hi Motoo,





    This happens when you define the same type several times. To avoid confusion with re-defining the same type from a different place, and then getting problems with calling functions that use this type for their parameters, TestComplete forbids redefining the types already defined during the test execution.





    So, please move the types definition code to a procedure that is called only once during a test execution.
  • Hello,



    That seems to have done the trick.  The error on InvalidateRect() is gone, too.  Thanks for help!



    Interesting to note that I also had to move User32DLL.DefineProc("InvalidateRect", vt_i4, defRect, vt_i4, vt_bool); to one-time execution.  But this one didn't throw exception.  It was only a warning.



    Motoo

  • Hi Motoo,





    Thanks for pointing this out! We will consider changing the DefineType method behavior, so it gives a warning just like DefineProc does.