What good is an OnItemChanged-event...
-
"Good" is a subjective term, and its true value is based entirely on the context of the phrase. "Good" programmers in India - That might be true in a few cases, but generally is considered an "outright lie". "Good" soldiers from France - those are the guys that don't mar the finish on their rifles when they throw them down during a headlong retreat. "Good" software from Microsoft - this is true only if you ask someone from Microsoft. The rest of the world claims this is a "damned lie". "Good" Linux distro - this is based on your ability to tolerate the need to use a command line utility to do things like change the resolution in XWindows. There are other examples but I'm getting bored. Maybe that's a "good" thing...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
"Good" Linux distro - this is based on your ability to tolerate the need to use a command line utility to do things like change the resolution in XWindows.
:laugh: :laugh: :laugh: :laugh: Getting a bit long in the tooth there mate. Personally I hate command line rubbish and have only used it on rare occasions, ( honestly read the book, there is 1 case of using a command line. ) As for XWindows, seriously, I have never seen one. I wouldn't even know how to run one.
pseudonym67 My Articles[^] Beginning KDevelop Programming[^]
-
...if you cannot change the contents of the grid inside it? The grid control assumes that I do not change the grid in any way. If I had another row as a consequence of editing certain cells within the grid, it crashes, because of stupid assumptions. Who designed this!? (That's a rhetorical question - I know who did, but I'm not going to divulge the name of the control library vendor - I don't want to be ignored in the support forums... I reckon the developers visit CP once in a while - who doesn't?) What is the point of the events if I can't really react on the event? The workaround: Defer the grid changes to a later stage - WM_KICKIDLE is an unsung hero. I should have listened to a former colleague of mine, and picked the other control library.
-- Kein Mitleid Für Die Mehrheit
-
Jörgen Sigvardsson wrote:
The workaround: Defer the grid changes to a later stage - WM_KICKIDLE is an unsung hero.
I'm fond of
SetTimer(hWnd, 0, 0, NULL)myself, but yeah. Short delays to avoid non-reentrant code...I can't wait for the new features from C++0x: lambda & closures. Then it'll be very easy devise a general mechanism for deferring code execution (independent of the mechanism that starts the execution).
-- Kein Mitleid Für Die Mehrheit
-
I can't wait for the new features from C++0x: lambda & closures. Then it'll be very easy devise a general mechanism for deferring code execution (independent of the mechanism that starts the execution).
-- Kein Mitleid Für Die Mehrheit
-
I only have the grid's public interface to work with. Those methods change the internal state of the control, and that is a no-no because the internal code, that calls my event handler, isn't prepared for those types of side effects. I *think* I can change the values inside cells, but I can't change the cells or rows themselves - cells and rows are allocated dynamically, and when moved, cached pointers in the calling context are invalidated.
-- Kein Mitleid Für Die Mehrheit
There is always the evergreen deferred execution method. Set a timer in OnItemChanged, and have its Timer event execute your code after the event handler has exited. :suss: Oops! :-O I initially skipped over your mention of WM_KICKIDLE.
-
Please elaborate on "Good" in the context of Russian programmers. (I think they're Russians :~)
-- Kein Mitleid Für Die Mehrheit
Oh no! I'm using the same suite, particularly the grid, but I don't need no stinking grid manipulation. But still, on the whole, I find their products to be very powerful and configurable, if not altogether intuitive. If you want intuitive and convenient, at the cost of scope for control, I would recommend DevExpress.
-
Oh no! I'm using the same suite, particularly the grid, but I don't need no stinking grid manipulation. But still, on the whole, I find their products to be very powerful and configurable, if not altogether intuitive. If you want intuitive and convenient, at the cost of scope for control, I would recommend DevExpress.
DevExpress is .NET only..? :~
-- Kein Mitleid Für Die Mehrheit
-
DevExpress is .NET only..? :~
-- Kein Mitleid Für Die Mehrheit
Yes, but it's not for you anyway - you want control over convenience. Have you posted your issue on the vendor forums? They've been pretty busy with a new release, so my questions in the component specific boards went unanswered, but when I re-posted them in general discussions last night, both were answered this morning. Oh, they're not Russian. ;P
-
Yes, but it's not for you anyway - you want control over convenience. Have you posted your issue on the vendor forums? They've been pretty busy with a new release, so my questions in the component specific boards went unanswered, but when I re-posted them in general discussions last night, both were answered this morning. Oh, they're not Russian. ;P
As soon as I get some time to do it. Right now I'm prioritizing my own product, than theirs. After all, I did find a solution. Even creepier, it turned out the error didn't stop with just deferring the execution. If I ended the cell edit using the keyboard (enter typically), it messes the selections up internally. Selected rows are updated accordingly when a new row is added, but the currently selected cell isn't. The selection is deleted, but the pointer is never set to NULL. Then in the next pass, the grid detects that the cell selection isn't NULL, so it tries to delete it. You know where that leads... The solution to the selection error was fairly easy: I just set current cell selection to NULL prior to adding a new cell. :) I bet the bug never shows up if you insert a row non-adjacent to the row of the selected cell. (I don't have time to find out - at the pace I'm currently coding, I will need a new keyboard by the end of March!)
-- Kein Mitleid Für Die Mehrheit
-
As soon as I get some time to do it. Right now I'm prioritizing my own product, than theirs. After all, I did find a solution. Even creepier, it turned out the error didn't stop with just deferring the execution. If I ended the cell edit using the keyboard (enter typically), it messes the selections up internally. Selected rows are updated accordingly when a new row is added, but the currently selected cell isn't. The selection is deleted, but the pointer is never set to NULL. Then in the next pass, the grid detects that the cell selection isn't NULL, so it tries to delete it. You know where that leads... The solution to the selection error was fairly easy: I just set current cell selection to NULL prior to adding a new cell. :) I bet the bug never shows up if you insert a row non-adjacent to the row of the selected cell. (I don't have time to find out - at the pace I'm currently coding, I will need a new keyboard by the end of March!)
-- Kein Mitleid Für Die Mehrheit
Jörgen Sigvardsson wrote:
Even creepier, it turned out the error didn't stop with just deferring the execution. If I ended the cell edit using the keyboard (enter typically), it messes the selections up internally. Selected rows are updated accordingly when a new row is added, but the currently selected cell isn't. The selection is deleted, but the pointer is never set to NULL. Then in the next pass, the grid detects that the cell selection isn't NULL, so it tries to delete it. You know where that leads...
:~ Sorry, but, rather you than me. ;P
-
John Simmons / outlaw programmer wrote:
"Good" Linux distro - this is based on your ability to tolerate the need to use a command line utility to do things like change the resolution in XWindows.
:laugh: :laugh: :laugh: :laugh: Getting a bit long in the tooth there mate. Personally I hate command line rubbish and have only used it on rare occasions, ( honestly read the book, there is 1 case of using a command line. ) As for XWindows, seriously, I have never seen one. I wouldn't even know how to run one.
pseudonym67 My Articles[^] Beginning KDevelop Programming[^]
As long as they keep recommending it, it's not obsolete. Whenever someone has a problem is Linux, almost every answer starts with the phrase, "Open a terminal window and...". What a crock.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Please elaborate on "Good" in the context of Russian programmers. (I think they're Russians :~)
-- Kein Mitleid Für Die Mehrheit
You think *who* are Russians?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
You think *who* are Russians?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001The vendor of [un]said grid control.
-- Kein Mitleid Für Die Mehrheit
-
...if you cannot change the contents of the grid inside it? The grid control assumes that I do not change the grid in any way. If I had another row as a consequence of editing certain cells within the grid, it crashes, because of stupid assumptions. Who designed this!? (That's a rhetorical question - I know who did, but I'm not going to divulge the name of the control library vendor - I don't want to be ignored in the support forums... I reckon the developers visit CP once in a while - who doesn't?) What is the point of the events if I can't really react on the event? The workaround: Defer the grid changes to a later stage - WM_KICKIDLE is an unsung hero. I should have listened to a former colleague of mine, and picked the other control library.
-- Kein Mitleid Für Die Mehrheit
Jörgen Sigvardsson wrote:
I should have listened to a former colleague of mine, and picked the other control library.
Are you sure the other control library doesn't suffer the same deficiency or perhaps other "unadvertised features"?
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
Jörgen Sigvardsson wrote:
I should have listened to a former colleague of mine, and picked the other control library.
Are you sure the other control library doesn't suffer the same deficiency or perhaps other "unadvertised features"?
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesOf course, I can't be sure of that.
-- Kein Mitleid Für Die Mehrheit
-
Of course, I can't be sure of that.
-- Kein Mitleid Für Die Mehrheit
Unfortunately, "unadvertised features" do not usually become apparent until after you purchase the product and put it through its paces. Check on Google to see if anyone else experienced the same problem and if they may have found a solution. Don't beat yourself up about it. It is easy to have 20/20 hindsight but a lot more difficult to predict the future outcome of a decision. There must have been something about this product that caused you to decide to purchase it over the other control library. Hopefully it wasn't just price! :doh: With a bit of luck you will find out how to accomplish what you want from the vendor, or some other source. Good luck with resolving this problem.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
...if you cannot change the contents of the grid inside it? The grid control assumes that I do not change the grid in any way. If I had another row as a consequence of editing certain cells within the grid, it crashes, because of stupid assumptions. Who designed this!? (That's a rhetorical question - I know who did, but I'm not going to divulge the name of the control library vendor - I don't want to be ignored in the support forums... I reckon the developers visit CP once in a while - who doesn't?) What is the point of the events if I can't really react on the event? The workaround: Defer the grid changes to a later stage - WM_KICKIDLE is an unsung hero. I should have listened to a former colleague of mine, and picked the other control library.
-- Kein Mitleid Für Die Mehrheit
Why not post a user-defined message, rather than the
WM_KICKIDLEor timer solutions, which may be indefinitely deferred? A user-defined message is guaranteed to be handled in a timely fashion.Software Zen:
delete this;
Fold With Us![^] -
Why not post a user-defined message, rather than the
WM_KICKIDLEor timer solutions, which may be indefinitely deferred? A user-defined message is guaranteed to be handled in a timely fashion.Software Zen:
delete this;
Fold With Us![^]I don't have that much going on in the message pump. If there is much action in the window pump, the modal dialog would be busy enough to not redraw itself. Since the operation I'm carrying out is of GUI characteristics, it wouldn't have mattered. I have not yet tried PostMessage(), but I suspect it could fail. If you PostMessage(), it is possibly put onto the message queue in between two grid messages. It could be that the "must execute" message is the last one. I also don't know how the message queue looks like at event time. The "must execute" message may not have been posted already - it could be the case that it is posted as a side effect of some other message. I thought that it would be best to let the grid run its course.
-- Kein Mitleid Für Die Mehrheit
