Subject | RE: [IBO] Using colorscheme |
---|---|
Author | Paul Vinkenoog |
Post date | 2003-05-13T12:25:16Z |
Hello Riho-Rene,
But the AfterEdit, AfterInsert, AfterDelete handlers are called later,
when the color has already been changed.
So you could write one handler procedure that simply copies the color
form an IB_Edit to other controls, without the need for a case
statement to check the actual state. Then you point AfterEdit,
AfterInsert etc. of your query to that one single handler.
You can even add in AfterSearch, AfterOpen, AfterUnprepare etc.
The only thing left uncovered is when you go back to browse state.
AfterPost and AfterCancel fire before the state change, so they are
useless. Too bad there isn't an AfterBrowse event to announce that the
dataset has gone back into browse state. For this you'd still need
OnStateChanged, not to check the color but to check the new state.
Someone mentioned OnGetDataLinkColor. This does work, but it's called
lots of times around every color change. (First before the color
change, and at least once for every column after the change).
It seems a bit "ugly" to use such an event to set colors, but... the
VCL components check the current color anyway before setting a new
one. So there's not much wasted CPU time and certainly no unnecessary
repaints. All in all, OnGetdataLinkColor is probably the best and the
simplest solution here.
Greetings,
Paul Vinkenoog
> The color copying didn't work :(.Played a bit with this and yes, color change comes after OnStateChanged.
> Well, have to write a long switch statement.
> (...)
> The color of IBO controls seems to be set after OnStateChanged event.
But the AfterEdit, AfterInsert, AfterDelete handlers are called later,
when the color has already been changed.
So you could write one handler procedure that simply copies the color
form an IB_Edit to other controls, without the need for a case
statement to check the actual state. Then you point AfterEdit,
AfterInsert etc. of your query to that one single handler.
You can even add in AfterSearch, AfterOpen, AfterUnprepare etc.
The only thing left uncovered is when you go back to browse state.
AfterPost and AfterCancel fire before the state change, so they are
useless. Too bad there isn't an AfterBrowse event to announce that the
dataset has gone back into browse state. For this you'd still need
OnStateChanged, not to check the color but to check the new state.
Someone mentioned OnGetDataLinkColor. This does work, but it's called
lots of times around every color change. (First before the color
change, and at least once for every column after the change).
It seems a bit "ugly" to use such an event to set colors, but... the
VCL components check the current color anyway before setting a new
one. So there's not much wasted CPU time and certainly no unnecessary
repaints. All in all, OnGetdataLinkColor is probably the best and the
simplest solution here.
Greetings,
Paul Vinkenoog