nanogui: Thread: Newbie problems

Hello everybody. This is my first message to the list. First of all,
apologizes for my bad english.

I'm part of the development of a new operating system. It's a little
project, for an embedded system (for a Motorola Dragonball based system,
the Olivetti daVinci PDA). So, I wrote the driver for the daVinci screen
(it's just a framebuffer supporting 1, 2 and 4bpp) and it seems to work
fine. I built it into the OS core, because the vt stuff uses it. Then, I
made little changes into the microwin 0.87 Makefile (because the
equivalent of device.h is into the OS), and I was able to compile and link
an OS with the microwindows stuff into. 

I've made a little demo that opens a window with a text message. I'm
attatching it just here because is a very little code, sorry:

#include <windows.h>

LRESULT CALLBACK wproc(HWND,UINT,WPARAM,LPARAM);

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
                   PSTR szCmdLine, int iCmdShow)
{
        static char szAppName[]="HolaWin";
        HWND hwnd;
        MSG msg;
        WNDCLASS wndclass;

        wndclass.style          = CS_DBLCLKS | CS_HREDRAW | CS_VREDRAW;
        wndclass.lpfnWndProc    = (WNDPROC)wproc;
        wndclass.cbClsExtra     =0;
        wndclass.cbWndExtra     =0;
        wndclass.hInstance      =0;
        wndclass.hIcon          =0;
        wndclass.hCursor        =0;
        wndclass.hbrBackground  =(HBRUSH)GetStockObject(LTGRAY_BRUSH);
        wndclass.lpszMenuName   =NULL;
        wndclass.lpszClassName  = szAppName;

        RegisterClass(&wndclass);
        hwnd=CreateWindowEx(0L,
                          szAppName,
                          "Hola",
                          WS_OVERLAPPEDWINDOW | WS_VISIBLE,
                          CW_USEDEFAULT,
                          CW_USEDEFAULT,
                          80,
                          80,
                          NULL,
                          NULL,
                          NULL,
                          NULL);
               
               
        ShowWindow(hwnd,iCmdShow);
        UpdateWindow(hwnd);
        
        while (GetMessage(&msg,NULL,0,0)) {
                TranslateMessage(&msg);
                DispatchMessage(&msg);
        }      
        return msg.wParam;
}       
LRESULT CALLBACK wproc(HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
{       
        HDC hdc;
        PAINTSTRUCT ps;
        RECT rect;
        
        switch (iMsg) {
        case WM_CREATE:
                break;
        case WM_PAINT:
        case WM_MOUSEFIRST:
                hdc=BeginPaint(hwnd,&ps);
                GetClientRect(hwnd,&rect);
                DrawText(hdc, "Hola, NOS", -1, &rect,
                         DT_SINGLELINE|DT_CENTER|DT_VCENTER);
                EndPaint(hwnd,&ps);
                break;
        case WM_DESTROY:
                PostQuitMessage(0);
                break;
        default:
                return DefWindowProc(hwnd,iMsg,wParam,lParam);
        }      
        return (0);
}

OK. I make no modifications into the winmain.c. After the calibration of
the screen (this is the last stage of the postboot), the desktop is
painted and them, the expected window paints, but after that, the Desktop
paints again and overwrites my window :-( . I added the WM_MOUSEFIRST, and
so, if I touch with the pen where the window should be, it is repainted. 

If I try to drag the window around the desktop, it works (well, the shape
of the window remains painted in every place) and them, the desktop
overwrites the little window as before.

I'm not sure of what could be happen. So, could anybody test my little
demo and say me how does it work in another platform. 

Should I need to made any change into the microwindows code because the
Dragonball, or differences bigendian and littleendian, etc.?

I think that the doubleclick doesn't works in my implementation. (The
window doesn't maximize when I doubleclick on the top bar) Could be
because my GetTickCount() only returns a 0L (non UNIX system) ?


Thank you very much for your time. 

-- 
     LLL       LLLLL  Manuel Teira Paz      Telefonica I+D     
    LLL       LLLLLLL Tfno: 34 91 337 9973  Infraestructura de Red (5240)
   LLL   L   LLL  LLL Fax:  34 91 337 4502  C/ Emilio Vargas, 6
  LLL  LLL  LLL  LLL  ####@####.####  28043 Madrid (Spain)
 LLL   L   LLLLLLL    --------------------------------------------------
LLL       LLLLL   "Sonreir cuando las cosas van mal, quiere decir que ya 
                   tienes a quien echarle la culpa"

After the calibration of
: the screen (this is the last stage of the postboot), the desktop is
: painted and them, the expected window paints, but after that, the Desktop
: paints again and overwrites my window :-( . I added the WM_MOUSEFIRST, and
: so, if I touch with the pen where the window should be, it is repainted. 
: 
: If I try to drag the window around the desktop, it works (well, the shape
: of the window remains painted in every place) and them, the desktop
: overwrites the little window as before.
: 
: I'm not sure of what could be happen. So, could anybody test my little
: demo and say me how does it work in another platform. 

I compiled up and tested your well-written test program and it
runs just fine on my Linux box.  I suspect that something else is
drawing the background screen over the contents of the Microwindows
program.

Now, there is the possibility, that for some reason the desktop
window clipping isn't working...  To test for this, go to the
DefWindowProc (windefw.c) which is the default window
procedure for the root window, and comment out the WM_PAINT
handler.  Then it won't paint.  



: 
: Should I need to made any change into the microwindows code because the
: Dragonball, or differences bigendian and littleendian, etc.?

Currently, you have to set BIGENDIAN=1 in the makefile.



: 
: I think that the doubleclick doesn't works in my implementation. (The
: window doesn't maximize when I doubleclick on the top bar) Could be
: because my GetTickCount() only returns a 0L (non UNIX system) ?

That's definetly it.  GetTickCount must return something other than 0
to time double-clicks.  Feel free to make it work for your OS.


Regards,

Greg

Thanks for your answers:

On Thu, 20 Jan 2000, Greg Haerr wrote:

> Now, there is the possibility, that for some reason the desktop
> window clipping isn't working...  To test for this, go to the
> DefWindowProc (windefw.c) which is the default window
> procedure for the root window, and comment out the WM_PAINT
> handler.  Then it won't paint.

OK. This could be the key. I'll try this night.
> 
> 
> 
> : 
> : Should I need to made any change into the microwindows code because the
> : Dragonball, or differences bigendian and littleendian, etc.?
> 
> Currently, you have to set BIGENDIAN=1 in the makefile.

OK, I'd made this change some days ago.

> : I think that the doubleclick doesn't works in my implementation. (The
> : window doesn't maximize when I doubleclick on the top bar) Could be
> : because my GetTickCount() only returns a 0L (non UNIX system) ?
> 
> That's definetly it.  GetTickCount must return something other than 0
> to time double-clicks.  Feel free to make it work for your OS.

I'm not sure about this point. I've compiled microwin for my Solaris box
and taken out the GetTicksCount() code, to return always 0L. The result is
that you can make a double click with an infinite delay, because the code
only checks the delay to be less than DBLCLICKSPEED, and it's always 0 in
our case. So this is not the reason of the problem.

I think that could be something related with the low level driver. It
works different than the x11 mouse driver, because the last one always
returns absolute positions (return 2). In my PDA, when the touchpad is
pressed I return the position and LBUTTON press (return 2), but when the
button is released, I return 3 and *bp=0, to show that the button has been
released. Isn't this the wright way? 

Yesterday night, I'd been tracing the events on the defWindowProc, and
when the strange fenomenom happens, there are a sequence of WM_NCPAINT for
the Desktop and the window. I'll try on the x11 compiled versión to see
the differences.

> 
> 
> Regards,
> 
> Greg
> 
> 
> 
Thank you very much. 

Best regards

--                                                                              
     LLL       LLLLL  Manuel Teira Paz      Telefonica I+D                      
    LLL       LLLLLLL Tfno: 34 91 337 9973  Infraestructura de Red (5240)       
   LLL   L   LLL  LLL Fax:  34 91 337 4502  C/ Emilio Vargas, 6                 
  LLL  LLL  LLL  LLL  ####@####.####  28043 Madrid (Spain)                
 LLL   L   LLLLLLL    --------------------------------------------------        
LLL       LLLLL   "Sonreir cuando las cosas van mal, quiere decir que ya        
                   tienes a quien echarle la culpa"                           

: I think that could be something related with the low level driver. It
: works different than the x11 mouse driver, because the last one always
: returns absolute positions (return 2). In my PDA, when the touchpad is
: pressed I return the position and LBUTTON press (return 2), but when the
: button is released, I return 3 and *bp=0, to show that the button has been
: released. Isn't this the wright way? 


Yeah, I think it's your driver.  Instead of returning 3, why don't you return
2 and include the old mouse coordinates.  I think that will work.  It seems
that we might have a fix required in the mid level when a driver returns 3:
it should use the old x,y values and probably isn't.  I'll check into this,
but you can probably get fixed by returning 2.

Regards,

Greg

On Fri, 21 Jan 2000, Greg Haerr wrote:

> Yeah, I think it's your driver.  Instead of returning 3, why don't you return
> 2 and include the old mouse coordinates.  I think that will work.  It seems
> that we might have a fix required in the mid level when a driver returns 3:
> it should use the old x,y values and probably isn't.  I'll check into this,
> but you can probably get fixed by returning 2.
> 
> Regards,
> 
> Greg
OK, I'm trying today that change. Anyway, I've found some things using
your ideas:

I've been tracing the behaviour of the little example I've written both in
X11 environment and the PDA. The key of the question is clipping (as you
wisely said :-o ), when the Desktop window gets the WM_PAINT event, the
GdFillRect calls GdClipArea and it returns CLIP_VISIBLE in the PDA
version, therefore in X11 version, it reaches the drawrow section of
GdClipRect (this is the right way) . I've been trying to understand all
the clipping related code, but I've got blind about it. Have you any idea?

The other missfunction is that when a window is dragged around the screen,
the shapes that are drawn  around the screen aren't cleared. I'll try to
explain: in X11 version, only one shape at a time is present; in the PDA
version, there are a lot of shapes of the screen at a time, and they are
only cleared when the pen is released, and everything is cleared because
of the last paragraph stuff.

One more time, thanks a lot.

Best regards.