Re: [AD] GUI - d_ctext_proc, file_select_ex, gui_textout_ex

[Esaelon@xxxxxxxxxx]

In a message dated 6/15/03 7:06:38 AM Eastern Daylight Time, 
elias@xxxxxxxxxx writes:

>  > d_ctext_proc() is not properly redrawn when it is told to redraw 
(MSG_DRAW 
> or 
>  > if another object returns D_REDRAW) when the mouse pointer is over it.  
> This 
>  > is caused by the text using the horizontal origin point as the center 
>  > location, yet the scare_mouse_area() code (kludge to reduce mouse 
pointer 
> flicker?) 
>  > relies on the entire viewable area of the object to be >= the horizontal 
> origin; 
>  > so text drawn to the left of the origin point is not properly handled.
>  
>  You have to set the d->x,y,w,h so it includes the complete text. To be
>  clear: If your text is 100 pixels wide and 10 pixels high, and you want
>  the top/center point to be at 300,300, your x,y,w,h would be this:
>  250,300,100,10. Just found this out right now by looking at the
>  d_ctext_proc code in guiproc.c btw., the docs are wrong about it.
>  Does this fix the problem?
Nope.  See, the text is centered on the x.  The scare_mouse_area() code 
scares the mouse out of the x to (x+w-1) and y to (y+h-1), yet the d_ctext_proc 
(optimally?) would use (x-w/2) to (x+w/2+1).  Hence, with the scare_mouse_area() 
kludge code, d_ctext_proc (and the similar proc used by the file selectors) 
are fundamentally broken with regards to their own redraw.

>  > file_select_ex() uses a similar function that has the same problem.
>  Probably the functions with c_text in their name, they just set their
>  with and height to 1. This should be changed I guess.
As I listed above, that alone would not help; the problem would still exist 
for the left half of the drawn text.

>  > Additionally, I was attempting to wrap d_text_proc() to automatically 
set the 
>  > display size of the object on MSG_START to save me some hassle; in doing 
so, 
>  > I realized that gui_textout_ex() is the only way to get the correct 
length for 
>  > a d_text_proc(); and that it does not support non-default FONTs, even 
though 
>  > d_text_proc() does.  It requires a kludge to swap the non-default font 
in as 
>  > default, do the call, and then swap it back.  d_text_proc() uses the 
same sort 
>  > of code to do the drawing.
>  That's per design of the Allegro GUI. The docs tell that, to change the
>  font, you have to point the global 'font' pointer to your new font.
>  gui_textout_ex() is a GUI function, so it behaves the same.
Not a very nice design, unfortunately, as getting the d_text_proc optimal 
size requires the same kludge that d_text_proc uses to draw non-default fonts, 
which is just that, a kludge.
>  
>  > I believe there was another issue, but I can't recall it at the moment.
>  There's lots. Recently, someone reported that menus still block when you
>  hold the mouse button after exiting them - this should be fixed as
>  well..
Yeah, that was me, also..


More later,
Charles Bilyué