What good is an OnItemChanged-event...
-
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