Home » Eclipse Projects » Standard Widget Toolkit (SWT) » LVS_OWNERDRAWFIXED in Table
|
| Re: LVS_OWNERDRAWFIXED in Table [message #450649 is a reply to message #450640] |
Wed, 16 February 2005 14:22   |
 Steve Northover
Messages: 1636
Registered: July 2009 |
Senior Member |
|
|
It's a dangerous path. For one thing, you'll be tied to Windows. Also, if
you set this style bit, the table will behave differently, possibly
invalidating all kinds of code and assumptions in the Table class. There
are also certain conceptual problems that come with owner draw. For
example, an owner draw table can't automatically scroll to an item when the
user types a letter because it has no idea what you are drawing. Either
every client needs to implement it or some other strategy needs to be worked
out. When I changed the Windows table to support SWT.VIRTUAL, I ended up
having to rewrite most of it. Hopefully, you won't need to do this. So, if
the only reason you are doing this is to work around 43910, I suggest that
you just live with it. Every other native Windows app has the same problem.
Have you investigated KTable?
"Brad Reynolds" <bradleyjames@gmail.com> wrote in message
news:cuvinl$33u$1@www.eclipse.org...
> There's a bug (43910) that addresses a problem with the windows ListView
> and states that the bug is in windows and that SWT's role is not to fix
> these bugs. I understand that stance but I'm trying to figure out how
> for my project I can create a usable Table for windows. For me it's
> still a problem and needs to be addressed. If via the Table interface I
> had the ability to set the LVS_OWNERDRAWFIXED style I'd be able to fix
> this. I'm going to have to do some custom drawing but I'm fine with
> that. My main concern is that via the API provided I can't specify this
> without extending the Table and overriding the widgetStyle() function.
> The problem with doing this is that the widgetStyle method will only be
> visible to me if I declare my class in the org.eclipse.swt.widgets
> package. I can do this but it just doesn't feel right, mainly the
> package that it has to reside in. I've read the documents on
> composition vs. extension and I'm fine with that but I don't see how I
> can create an appropriate solution without extending the Table and since
> for me this is a bug fix, no matter where the bug is, I don't have a
> problem with committing this SWT sin.
>
> The reasons I want to still extend the SWT Table and not go completely
> custom are:
> * I will still be able to leverage any existing documentation for Table
> for my consumers. To me this is huge. The more documentation whether
> it be API or just code snippets that exist for my consumers the better
> and by creating a custom component I'll have to start over.
> * The event model is already defined and works as expected.
>
> My question is is there something that I'm overlooking? Am I heading
> down the wrong path?
>
> Thanks,
> Brad
|
|
|
| Re: LVS_OWNERDRAWFIXED in Table [message #450650 is a reply to message #450649] |
Wed, 16 February 2005 14:57 |
Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
Thank you for the response and advice. I'm not just wanting to do this
for that one bug, I was just using it as an example. There are other
enhancements that are needed like having multiple icons in a cell and
maybe even a custom header. I need to step back and reevaluate my
position on this. I appreciate the response and insight.
As for KTable I have nothing against the component/company/developer but
to base a large solution on something that seems to have little support
or documentation is something that's hard for me to do. If I was
writing an application that was for something smaller I wouldn't mind.
But we've been burnt by these types of projects before so adopting
KTable is rather risky at this point for me and my company. Also I
haven't seen much on the site about cross platform look and feel.
Steve Northover wrote:
> It's a dangerous path. For one thing, you'll be tied to Windows. Also, if
> you set this style bit, the table will behave differently, possibly
> invalidating all kinds of code and assumptions in the Table class. There
> are also certain conceptual problems that come with owner draw. For
> example, an owner draw table can't automatically scroll to an item when the
> user types a letter because it has no idea what you are drawing. Either
> every client needs to implement it or some other strategy needs to be worked
> out. When I changed the Windows table to support SWT.VIRTUAL, I ended up
> having to rewrite most of it. Hopefully, you won't need to do this. So, if
> the only reason you are doing this is to work around 43910, I suggest that
> you just live with it. Every other native Windows app has the same problem.
>
> Have you investigated KTable?
>
> "Brad Reynolds" <bradleyjames@gmail.com> wrote in message
> news:cuvinl$33u$1@www.eclipse.org...
>
>>There's a bug (43910) that addresses a problem with the windows ListView
>>and states that the bug is in windows and that SWT's role is not to fix
>>these bugs. I understand that stance but I'm trying to figure out how
>>for my project I can create a usable Table for windows. For me it's
>>still a problem and needs to be addressed. If via the Table interface I
>>had the ability to set the LVS_OWNERDRAWFIXED style I'd be able to fix
>>this. I'm going to have to do some custom drawing but I'm fine with
>>that. My main concern is that via the API provided I can't specify this
>>without extending the Table and overriding the widgetStyle() function.
>>The problem with doing this is that the widgetStyle method will only be
>>visible to me if I declare my class in the org.eclipse.swt.widgets
>>package. I can do this but it just doesn't feel right, mainly the
>>package that it has to reside in. I've read the documents on
>>composition vs. extension and I'm fine with that but I don't see how I
>>can create an appropriate solution without extending the Table and since
>>for me this is a bug fix, no matter where the bug is, I don't have a
>>problem with committing this SWT sin.
>>
>>The reasons I want to still extend the SWT Table and not go completely
>>custom are:
>>* I will still be able to leverage any existing documentation for Table
>>for my consumers. To me this is huge. The more documentation whether
>>it be API or just code snippets that exist for my consumers the better
>>and by creating a custom component I'll have to start over.
>>* The event model is already defined and works as expected.
>>
>>My question is is there something that I'm overlooking? Am I heading
>>down the wrong path?
>>
>>Thanks,
>>Brad
>
>
>
|
|
|
| Re: LVS_OWNERDRAWFIXED in Table [message #450757 is a reply to message #450650] |
Thu, 17 February 2005 18:28 |
Steve Northover
Messages: 1636
Registered: July 2009 |
Senior Member |
|
|
I don't think that LVS_OWNERDRAWFIXED will help you with the header. As for
multiple icons, Eclipse uses overlays.
"Brad Reynolds" <bradleyjames@gmail.com> wrote in message
news:cuvn1e$pvc$1@www.eclipse.org...
> Thank you for the response and advice. I'm not just wanting to do this
> for that one bug, I was just using it as an example. There are other
> enhancements that are needed like having multiple icons in a cell and
> maybe even a custom header. I need to step back and reevaluate my
> position on this. I appreciate the response and insight.
>
> As for KTable I have nothing against the component/company/developer but
> to base a large solution on something that seems to have little support
> or documentation is something that's hard for me to do. If I was
> writing an application that was for something smaller I wouldn't mind.
> But we've been burnt by these types of projects before so adopting
> KTable is rather risky at this point for me and my company. Also I
> haven't seen much on the site about cross platform look and feel.
>
> Steve Northover wrote:
> > It's a dangerous path. For one thing, you'll be tied to Windows. Also,
if
> > you set this style bit, the table will behave differently, possibly
> > invalidating all kinds of code and assumptions in the Table class.
There
> > are also certain conceptual problems that come with owner draw. For
> > example, an owner draw table can't automatically scroll to an item when
the
> > user types a letter because it has no idea what you are drawing. Either
> > every client needs to implement it or some other strategy needs to be
worked
> > out. When I changed the Windows table to support SWT.VIRTUAL, I ended up
> > having to rewrite most of it. Hopefully, you won't need to do this.
So, if
> > the only reason you are doing this is to work around 43910, I suggest
that
> > you just live with it. Every other native Windows app has the same
problem.
> >
> > Have you investigated KTable?
> >
> > "Brad Reynolds" <bradleyjames@gmail.com> wrote in message
> > news:cuvinl$33u$1@www.eclipse.org...
> >
> >>There's a bug (43910) that addresses a problem with the windows ListView
> >>and states that the bug is in windows and that SWT's role is not to fix
> >>these bugs. I understand that stance but I'm trying to figure out how
> >>for my project I can create a usable Table for windows. For me it's
> >>still a problem and needs to be addressed. If via the Table interface I
> >>had the ability to set the LVS_OWNERDRAWFIXED style I'd be able to fix
> >>this. I'm going to have to do some custom drawing but I'm fine with
> >>that. My main concern is that via the API provided I can't specify this
> >>without extending the Table and overriding the widgetStyle() function.
> >>The problem with doing this is that the widgetStyle method will only be
> >>visible to me if I declare my class in the org.eclipse.swt.widgets
> >>package. I can do this but it just doesn't feel right, mainly the
> >>package that it has to reside in. I've read the documents on
> >>composition vs. extension and I'm fine with that but I don't see how I
> >>can create an appropriate solution without extending the Table and since
> >>for me this is a bug fix, no matter where the bug is, I don't have a
> >>problem with committing this SWT sin.
> >>
> >>The reasons I want to still extend the SWT Table and not go completely
> >>custom are:
> >>* I will still be able to leverage any existing documentation for Table
> >>for my consumers. To me this is huge. The more documentation whether
> >>it be API or just code snippets that exist for my consumers the better
> >>and by creating a custom component I'll have to start over.
> >>* The event model is already defined and works as expected.
> >>
> >>My question is is there something that I'm overlooking? Am I heading
> >>down the wrong path?
> >>
> >>Thanks,
> >>Brad
> >
> >
> >
|
|
|
| Re: LVS_OWNERDRAWFIXED in Table [message #450768 is a reply to message #450757] |
Thu, 17 February 2005 22:24 |
Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
Yeah, for the header I was going to have to hide it and write my own.
It was going to be a lot of work for little benefit really. I don't
quite understand the overlays comment though. Can you expand on that or
point me to an example?
Steve Northover wrote:
> I don't think that LVS_OWNERDRAWFIXED will help you with the header. As for
> multiple icons, Eclipse uses overlays.
>
> "Brad Reynolds" <bradleyjames@gmail.com> wrote in message
> news:cuvn1e$pvc$1@www.eclipse.org...
>
>>Thank you for the response and advice. I'm not just wanting to do this
>>for that one bug, I was just using it as an example. There are other
>>enhancements that are needed like having multiple icons in a cell and
>>maybe even a custom header. I need to step back and reevaluate my
>>position on this. I appreciate the response and insight.
>>
>>As for KTable I have nothing against the component/company/developer but
>>to base a large solution on something that seems to have little support
>>or documentation is something that's hard for me to do. If I was
>>writing an application that was for something smaller I wouldn't mind.
>>But we've been burnt by these types of projects before so adopting
>>KTable is rather risky at this point for me and my company. Also I
>>haven't seen much on the site about cross platform look and feel.
>>
>>Steve Northover wrote:
>>
>>>It's a dangerous path. For one thing, you'll be tied to Windows. Also,
>
> if
>
>>>you set this style bit, the table will behave differently, possibly
>>>invalidating all kinds of code and assumptions in the Table class.
>
> There
>
>>>are also certain conceptual problems that come with owner draw. For
>>>example, an owner draw table can't automatically scroll to an item when
>
> the
>
>>>user types a letter because it has no idea what you are drawing. Either
>>>every client needs to implement it or some other strategy needs to be
>
> worked
>
>>>out. When I changed the Windows table to support SWT.VIRTUAL, I ended up
>>>having to rewrite most of it. Hopefully, you won't need to do this.
>
> So, if
>
>>>the only reason you are doing this is to work around 43910, I suggest
>
> that
>
>>>you just live with it. Every other native Windows app has the same
>
> problem.
>
>>>Have you investigated KTable?
>>>
>>>"Brad Reynolds" <bradleyjames@gmail.com> wrote in message
>>>news:cuvinl$33u$1@www.eclipse.org...
>>>
>>>
>>>>There's a bug (43910) that addresses a problem with the windows ListView
>>>>and states that the bug is in windows and that SWT's role is not to fix
>>>>these bugs. I understand that stance but I'm trying to figure out how
>>>>for my project I can create a usable Table for windows. For me it's
>>>>still a problem and needs to be addressed. If via the Table interface I
>>>>had the ability to set the LVS_OWNERDRAWFIXED style I'd be able to fix
>>>>this. I'm going to have to do some custom drawing but I'm fine with
>>>>that. My main concern is that via the API provided I can't specify this
>>>>without extending the Table and overriding the widgetStyle() function.
>>>>The problem with doing this is that the widgetStyle method will only be
>>>>visible to me if I declare my class in the org.eclipse.swt.widgets
>>>>package. I can do this but it just doesn't feel right, mainly the
>>>>package that it has to reside in. I've read the documents on
>>>>composition vs. extension and I'm fine with that but I don't see how I
>>>>can create an appropriate solution without extending the Table and since
>>>>for me this is a bug fix, no matter where the bug is, I don't have a
>>>>problem with committing this SWT sin.
>>>>
>>>>The reasons I want to still extend the SWT Table and not go completely
>>>>custom are:
>>>>* I will still be able to leverage any existing documentation for Table
>>>>for my consumers. To me this is huge. The more documentation whether
>>>>it be API or just code snippets that exist for my consumers the better
>>>>and by creating a custom component I'll have to start over.
>>>>* The event model is already defined and works as expected.
>>>>
>>>>My question is is there something that I'm overlooking? Am I heading
>>>>down the wrong path?
>>>>
>>>>Thanks,
>>>>Brad
>>>
>>>
>>>
>
>
|
|
|
| Re: LVS_OWNERDRAWFIXED in Table [message #450842 is a reply to message #450768] |
Fri, 18 February 2005 15:02 |
Steve Northover
Messages: 1636
Registered: July 2009 |
Senior Member |
|
|
Instead of having multiple icons in a row, Eclipse uses one icon but
decorates it (this involves combining icons to create a single new icon and
setting that).
"Brad Reynolds" <bradleyjames@gmail.com> wrote in message
news:cv35i2$b0h$1@www.eclipse.org...
> Yeah, for the header I was going to have to hide it and write my own.
> It was going to be a lot of work for little benefit really. I don't
> quite understand the overlays comment though. Can you expand on that or
> point me to an example?
>
> Steve Northover wrote:
> > I don't think that LVS_OWNERDRAWFIXED will help you with the header. As
for
> > multiple icons, Eclipse uses overlays.
> >
> > "Brad Reynolds" <bradleyjames@gmail.com> wrote in message
> > news:cuvn1e$pvc$1@www.eclipse.org...
> >
> >>Thank you for the response and advice. I'm not just wanting to do this
> >>for that one bug, I was just using it as an example. There are other
> >>enhancements that are needed like having multiple icons in a cell and
> >>maybe even a custom header. I need to step back and reevaluate my
> >>position on this. I appreciate the response and insight.
> >>
> >>As for KTable I have nothing against the component/company/developer but
> >>to base a large solution on something that seems to have little support
> >>or documentation is something that's hard for me to do. If I was
> >>writing an application that was for something smaller I wouldn't mind.
> >>But we've been burnt by these types of projects before so adopting
> >>KTable is rather risky at this point for me and my company. Also I
> >>haven't seen much on the site about cross platform look and feel.
> >>
> >>Steve Northover wrote:
> >>
> >>>It's a dangerous path. For one thing, you'll be tied to Windows.
Also,
> >
> > if
> >
> >>>you set this style bit, the table will behave differently, possibly
> >>>invalidating all kinds of code and assumptions in the Table class.
> >
> > There
> >
> >>>are also certain conceptual problems that come with owner draw. For
> >>>example, an owner draw table can't automatically scroll to an item when
> >
> > the
> >
> >>>user types a letter because it has no idea what you are drawing.
Either
> >>>every client needs to implement it or some other strategy needs to be
> >
> > worked
> >
> >>>out. When I changed the Windows table to support SWT.VIRTUAL, I ended
up
> >>>having to rewrite most of it. Hopefully, you won't need to do this.
> >
> > So, if
> >
> >>>the only reason you are doing this is to work around 43910, I suggest
> >
> > that
> >
> >>>you just live with it. Every other native Windows app has the same
> >
> > problem.
> >
> >>>Have you investigated KTable?
> >>>
> >>>"Brad Reynolds" <bradleyjames@gmail.com> wrote in message
> >>>news:cuvinl$33u$1@www.eclipse.org...
> >>>
> >>>
> >>>>There's a bug (43910) that addresses a problem with the windows
ListView
> >>>>and states that the bug is in windows and that SWT's role is not to
fix
> >>>>these bugs. I understand that stance but I'm trying to figure out how
> >>>>for my project I can create a usable Table for windows. For me it's
> >>>>still a problem and needs to be addressed. If via the Table interface
I
> >>>>had the ability to set the LVS_OWNERDRAWFIXED style I'd be able to fix
> >>>>this. I'm going to have to do some custom drawing but I'm fine with
> >>>>that. My main concern is that via the API provided I can't specify
this
> >>>>without extending the Table and overriding the widgetStyle() function.
> >>>>The problem with doing this is that the widgetStyle method will only
be
> >>>>visible to me if I declare my class in the org.eclipse.swt.widgets
> >>>>package. I can do this but it just doesn't feel right, mainly the
> >>>>package that it has to reside in. I've read the documents on
> >>>>composition vs. extension and I'm fine with that but I don't see how I
> >>>>can create an appropriate solution without extending the Table and
since
> >>>>for me this is a bug fix, no matter where the bug is, I don't have a
> >>>>problem with committing this SWT sin.
> >>>>
> >>>>The reasons I want to still extend the SWT Table and not go completely
> >>>>custom are:
> >>>>* I will still be able to leverage any existing documentation for
Table
> >>>>for my consumers. To me this is huge. The more documentation whether
> >>>>it be API or just code snippets that exist for my consumers the better
> >>>>and by creating a custom component I'll have to start over.
> >>>>* The event model is already defined and works as expected.
> >>>>
> >>>>My question is is there something that I'm overlooking? Am I heading
> >>>>down the wrong path?
> >>>>
> >>>>Thanks,
> >>>>Brad
> >>>
> >>>
> >>>
> >
> >
|
|
|
| Re: LVS_OWNERDRAWFIXED in Table [message #450853 is a reply to message #450842] |
Fri, 18 February 2005 15:45 |
Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
I see. I'll look into that. Thanks a lot for the help, I appreciate it.
Steve Northover wrote:
> Instead of having multiple icons in a row, Eclipse uses one icon but
> decorates it (this involves combining icons to create a single new icon and
> setting that).
>
> "Brad Reynolds" <bradleyjames@gmail.com> wrote in message
> news:cv35i2$b0h$1@www.eclipse.org...
>
>>Yeah, for the header I was going to have to hide it and write my own.
>>It was going to be a lot of work for little benefit really. I don't
>>quite understand the overlays comment though. Can you expand on that or
>>point me to an example?
>>
>>Steve Northover wrote:
>>
>>>I don't think that LVS_OWNERDRAWFIXED will help you with the header. As
>
> for
>
>>>multiple icons, Eclipse uses overlays.
>>>
>>>"Brad Reynolds" <bradleyjames@gmail.com> wrote in message
>>>news:cuvn1e$pvc$1@www.eclipse.org...
>>>
>>>
>>>>Thank you for the response and advice. I'm not just wanting to do this
>>>>for that one bug, I was just using it as an example. There are other
>>>>enhancements that are needed like having multiple icons in a cell and
>>>>maybe even a custom header. I need to step back and reevaluate my
>>>>position on this. I appreciate the response and insight.
>>>>
>>>>As for KTable I have nothing against the component/company/developer but
>>>>to base a large solution on something that seems to have little support
>>>>or documentation is something that's hard for me to do. If I was
>>>>writing an application that was for something smaller I wouldn't mind.
>>>>But we've been burnt by these types of projects before so adopting
>>>>KTable is rather risky at this point for me and my company. Also I
>>>>haven't seen much on the site about cross platform look and feel.
>>>>
>>>>Steve Northover wrote:
>>>>
>>>>
>>>>>It's a dangerous path. For one thing, you'll be tied to Windows.
>
> Also,
>
>>>if
>>>
>>>
>>>>>you set this style bit, the table will behave differently, possibly
>>>>>invalidating all kinds of code and assumptions in the Table class.
>>>
>>>There
>>>
>>>
>>>>>are also certain conceptual problems that come with owner draw. For
>>>>>example, an owner draw table can't automatically scroll to an item when
>>>
>>>the
>>>
>>>
>>>>>user types a letter because it has no idea what you are drawing.
>
> Either
>
>>>>>every client needs to implement it or some other strategy needs to be
>>>
>>>worked
>>>
>>>
>>>>>out. When I changed the Windows table to support SWT.VIRTUAL, I ended
>
> up
>
>>>>>having to rewrite most of it. Hopefully, you won't need to do this.
>>>
>>>So, if
>>>
>>>
>>>>>the only reason you are doing this is to work around 43910, I suggest
>>>
>>>that
>>>
>>>
>>>>>you just live with it. Every other native Windows app has the same
>>>
>>>problem.
>>>
>>>
>>>>>Have you investigated KTable?
>>>>>
>>>>>"Brad Reynolds" <bradleyjames@gmail.com> wrote in message
>>>>>news:cuvinl$33u$1@www.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>>There's a bug (43910) that addresses a problem with the windows
>
> ListView
>
>>>>>>and states that the bug is in windows and that SWT's role is not to
>
> fix
>
>>>>>>these bugs. I understand that stance but I'm trying to figure out how
>>>>>>for my project I can create a usable Table for windows. For me it's
>>>>>>still a problem and needs to be addressed. If via the Table interface
>
> I
>
>>>>>>had the ability to set the LVS_OWNERDRAWFIXED style I'd be able to fix
>>>>>>this. I'm going to have to do some custom drawing but I'm fine with
>>>>>>that. My main concern is that via the API provided I can't specify
>
> this
>
>>>>>>without extending the Table and overriding the widgetStyle() function.
>>>>>>The problem with doing this is that the widgetStyle method will only
>
> be
>
>>>>>>visible to me if I declare my class in the org.eclipse.swt.widgets
>>>>>>package. I can do this but it just doesn't feel right, mainly the
>>>>>>package that it has to reside in. I've read the documents on
>>>>>>composition vs. extension and I'm fine with that but I don't see how I
>>>>>>can create an appropriate solution without extending the Table and
>
> since
>
>>>>>>for me this is a bug fix, no matter where the bug is, I don't have a
>>>>>>problem with committing this SWT sin.
>>>>>>
>>>>>>The reasons I want to still extend the SWT Table and not go completely
>>>>>>custom are:
>>>>>>* I will still be able to leverage any existing documentation for
>
> Table
>
>>>>>>for my consumers. To me this is huge. The more documentation whether
>>>>>>it be API or just code snippets that exist for my consumers the better
>>>>>>and by creating a custom component I'll have to start over.
>>>>>>* The event model is already defined and works as expected.
>>>>>>
>>>>>>My question is is there something that I'm overlooking? Am I heading
>>>>>>down the wrong path?
>>>>>>
>>>>>>Thanks,
>>>>>>Brad
>>>>>
>>>>>
>>>>>
>>>
>
>
|
|
|
Goto Forum:
Current Time: Mon Sep 23 17:45:22 GMT 2024
Powered by FUDForum. Page generated in 0.04761 seconds |
] 
Search
Help
Register
Login
Home
