Menu
▾
▴
adobe-source-devel
|
From: Thomas W. <wi...@ac...> - 2006-01-04 04:45:44
|
Hi, attached are sheets that demonstrate what I think are nesting issues with the group widget on Windows. On Windows XP the nested group uses a bigger font for the group name and the overlay displays as one black block. Regards Thomas -- Thomas Witt wi...@ac... |
|
From: Mat M. <mm...@em...> - 2006-01-05 02:06:38
|
> -----Original Message----- > From: ado...@li... > [mailto:ado...@li...] On > Behalf Of Thomas Witt > Sent: Tuesday, January 03, 2006 8:46 PM > To: ado...@li... > Subject: [Adobe-source-devel] group nesting issues windows > > > Hi, > > attached are sheets that demonstrate what I think are nesting > issues with the group widget on Windows. On Windows XP the > nested group uses a bigger font for the group name and the > overlay displays as one black block. Hi Thomas, I spent a bit of time looking into this today to see if I could fix it for the the upcoming release. The presence of the overlay group is definitely interfering with the proper drawing of the panel/static-text. As you probably know, groups are implemented as buttons in the Win32 API. Worse yet, groups seem to prevent messages from being passed between child<->parent. In the last release I trapped the group window_proc to propagate messages, but perhaps I didn't go far enough? I ran Begin with your group.* files and with a modified version that set Overlay to a row instead of a group. Drawing worked fine in the latter but as you point out, a black box is drawn in the first case. Interestingly, a Spy++ capture shows WM_GETTEXT and WM_PAINT messages in each case. As a result, I am working with the idea that the text is getting drawn, but something additional is getting drawn/erased and obscuring the text in the group case. I am just coming up to speed on Win32 API programming, so I welcome any suggestions at this point. - Mat |
|
From: Sean P. <sp...@ad...> - 2006-01-05 04:00:43
|
I'm not that familiar with the Win32 API but is this a necessity? How are groups normally handled on Win32? There isn't any Eve requirement that they look similar to the Mac implementation or anything - we should do them however they are normally done on Windows. On Jan 4, 2006, at 6:08 PM, Mat Marcus wrote: > As you > probably know, groups are implemented as buttons in the Win32 API. |
|
From: Thomas W. <wi...@ac...> - 2006-01-05 06:40:57
|
Hi Mat, On Jan 4, 2006, at 6:08 PM, Mat Marcus wrote: > > I spent a bit of time looking into this today to see if I could fix > it for > the the upcoming release. Thanks! > The presence of the overlay group is definitely > interfering with the proper drawing of the panel/static-text. As you > probably know, groups are implemented as buttons in the Win32 API. Yep, seems natural doesn't it? > > I ran Begin with your group.* files and with a modified version > that set > Overlay to a row instead of a group. Drawing worked fine in the > latter but > as you point out, a black box is drawn in the first case. > Interestingly, a > Spy++ capture shows WM_GETTEXT and WM_PAINT messages in each case. > As a > result, I am working with the idea that the text is getting drawn, but > something additional is getting drawn/erased and obscuring the text > in the > group case. I am just coming up to speed on Win32 API programming, > so I > welcome any suggestions at this point. I have to admit I am at a loss here. So far the Win32 API has withstood all my attempts to approach it using logic and inference. It seems the only way to make sense of it is to memorize an infinite number of idiosyncrasies. Unfortunately I am not really good at that. Thomas Thomas Witt wi...@ac... |
|
From: Steve T. <sti...@ad...> - 2006-01-05 13:01:39
|
> As a result, I am working with the idea that the text is getting=20 > drawn, but something additional is getting drawn/erased and obscuring=20 > the text in the group case.=20 I'm guessing what you're seeing is the group box painting itself after the button has been painted and since the group box's extent covers the button, it would be erasing it. Controls are painted in the order they're created I believe, but this is also controlled by the WS_CLIPSIBLINGS window style. If this isn't set, then one button can paint over another one that's on top of it - it's an optimization thing. Perhaps setting this style will prevent what you're seeing. -- Steve Tibbett sti...@ad... |
|
From: Mat M. <mm...@em...> - 2006-01-06 04:02:18
|
> -----Original Message----- > From: ado...@li... > [mailto:ado...@li...] On > Behalf Of Steve Tibbett > Sent: Thursday, January 05, 2006 5:07 AM > To: Thomas Witt; Mat Marcus > Cc: ado...@li... > Subject: RE: [Adobe-source-devel] group nesting issues windows > > > As a result, I am working with the idea that the text is getting > > drawn, but something additional is getting drawn/erased and > obscuring > > the text in the group case. > > I'm guessing what you're seeing is the group box painting > itself after the button has been painted and since the group > box's extent covers the button, it would be erasing it. > > Controls are painted in the order they're created I believe, > but this is also controlled by the WS_CLIPSIBLINGS window > style. If this isn't set, then one button can paint over > another one that's on top of it - it's an optimization thing. > Perhaps setting this style will prevent what you're seeing. Thanks for the suggestion Steve. I read up on that option and explored such solutions for a while. In this case the issues turned out to be with the panel windowproc. Ralph Thomas stepped in at the 11th hour and came up with a patch to clear up the main issues that Thomas Witt identified. While some additional Win32 bugs remain to be cleared up, Release 1.0.12 should allow him to make more progress. Please let us know. - Mat |
|
From: Ralph T. <ra...@gm...> - 2006-01-06 17:41:35
|
This kind of thing:
group() { panel() { static_text( name: "blah" ); } }
now works well, but this kind of thing:
tab_group() { panel() { panel() { static_text( name: "blah" ); } } }
shows grey behind the static text widget (instead of the tab group
texture, which is a subtle white-grey gradient on the default Windows
XP visual style). This bug was present in previous versions of ASL too
though, so there is no regression. I'll try to work on a fix tonight.
There is also a bug that Foster mentioned where a button inside a
group has a mysterious border around it. I investigated that last
night but haven't found out why yet (it might be the way that the
parent button [the group] handles the WM_CTLCOLORBUTTON message, but
I'm not sure).
Ralph
On 1/5/06, Mat Marcus <mm...@em...> wrote:
> > -----Original Message-----
> > From: ado...@li...
> > [mailto:ado...@li...] On
> > Behalf Of Steve Tibbett
> > Sent: Thursday, January 05, 2006 5:07 AM
> > To: Thomas Witt; Mat Marcus
> > Cc: ado...@li...
> > Subject: RE: [Adobe-source-devel] group nesting issues windows
> >
> > > As a result, I am working with the idea that the text is getting
> > > drawn, but something additional is getting drawn/erased and
> > obscuring
> > > the text in the group case.
> >
> > I'm guessing what you're seeing is the group box painting
> > itself after the button has been painted and since the group
> > box's extent covers the button, it would be erasing it.
> >
> > Controls are painted in the order they're created I believe,
> > but this is also controlled by the WS_CLIPSIBLINGS window
> > style. If this isn't set, then one button can paint over
> > another one that's on top of it - it's an optimization thing.
> > Perhaps setting this style will prevent what you're seeing.
>
> Thanks for the suggestion Steve. I read up on that option and explored su=
ch
> solutions for a while. In this case the issues turned out to be with the
> panel windowproc. Ralph Thomas stepped in at the 11th hour and came up wi=
th
> a patch to clear up the main issues that Thomas Witt identified. While so=
me
> additional Win32 bugs remain to be cleared up, Release 1.0.12 should allo=
w
> him to make more progress. Please let us know.
>
> - Mat
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
|
|
From: Thomas W. <wi...@ac...> - 2006-01-05 21:37:21
|
Mat, On Jan 4, 2006, at 6:08 PM, Mat Marcus wrote: > I ran Begin with your group.* files and with a modified version =20 > that set > Overlay to a row instead of a group. Drawing worked fine in the =20 > latter but > as you point out, a black box is drawn in the first case. =20 > Interestingly, a > Spy++ capture shows WM_GETTEXT and WM_PAINT messages in each case. =20 > As a > result, I am working with the idea that the text is getting drawn, but > something additional is getting drawn/erased and obscuring the text =20= > in the > group case. Hmm=85 there is another option: The static text does not draw its =20 background correctly. Interestingly nesting another panel in the =20 panel that's already there will make the static text paint correctly. No idea what to make of this. Thomas Thomas Witt wi...@ac... |
|
From: Thomas W. <wi...@ac...> - 2006-01-05 22:09:12
|
On Jan 5, 2006, at 1:37 PM, Thomas Witt wrote: > Hmm=85 there is another option: The static text does not draw its =20 > background correctly. Interestingly nesting another panel in the =20 > panel that's already there will make the static text paint correctly. Here is another interesting experiment: Nest the nested group box =20 "Bar" in a panel. ;-) Thomas Witt wi...@ac... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X