FWD » Core Development » User Interface

Also, this code in Browse.goUp doesn't seem valid:

...
else if (!isSelectionMultiple() && fireValueChanged)
{
   invokeRowEntryTrigger(true);    // <-----

The code in 4239a 11329-11330 is good.

Please merge these changes into 4103a and dead-archive 4239a.

Changes were merged into 4103a rev 11341. Branch 4239a was dead-archived.

Is 4103a going to be merged into trunk soon?

4103a has been rebased and is in testing right now. Do you need it for #3940?

4103a has been rebased and is in testing right now. Do you need it for #3940?

It probably would be nice to have it.

Stanislav Lomany wrote:

4103a has been rebased and is in testing right now. Do you need it for #3940?

It probably would be nice to have it.

You can branch from 4103a and then apply the 3940a diffs on top.

I suppose it's the best place to put a testcase that demonstrates unwanted row-entry events and duplicate row-entry events in FWD.

1. The first row-entry event is raised as a reaction to the entry event. Note than the event at this point is triggered for the current browse row, not the clicked row.
2. Mouse click event handler raises the second row-entry event for the clicked row.

Basically I want to avoid raising row-entry if an entry event was generated by mouse click (as opposed to, say, the case when the entry event was generated when the browse gets the focus because of a key press). Browse gets entry earlier than the mouse event, so I cannot set some state within browse (and don't actually want).

How can I do it - by adding another field to KeyInput to extend the entry event?

You could create a subclass of KeyInput for use with entry events.

Greg, also there's a FocusEvent generated by requestFocus called right after the row entry event is generated, which starts unplanned startEdit. Should I subclass FocusEvent this time?

Yes, that would be OK as well.

4103a is in trunk. Please put your changes in 4335a.

Please put your changes in 4335a.

I was going to put them into 4231b as they seem to be more risky. Is it OK?

Yes, 4231b is fine.

Fix for double ROW-ENTRY events is committed into 4231b rev 11472. Please review.

Code review 4231b review 11472.

Please also test the case when you click in a browse, without focus, directly in an editable cell. If I interpret your changes correctly, the cell will not start edit. But I wonder if the edit should be started.

I don't think EntryEvent class is the way to go. At this level of granularity we should also create classes for SE_LEAVE and other synthetic events, which obviously doesn't make sense. If new class I think it would make sense to introduce something like SyntheticKeyInput and cover all synthetic codes. But even this I don't think is necessary. Also considering how complex our eventing system is already, this could introduce issues.

Since we already use a mouse discriminator field in other event classes, and since the ExtendedFocusEvent class has no other purpose, I would remove the class and just put mouse field in FocusEvent.

Please also test the case when you click in a browse, without focus, directly in an editable cell. If I interpret your changes correctly, the cell will not start edit. But I wonder if the edit should be started.

This purpose of this task is to fix exactly this case. Yes, the editing should be started.

I don't think EntryEvent class is the way to go... I would remove the class and just put mouse field in FocusEvent.

I don't mind putting an extra boolean into FocusEvent and to create SyntheticKeyInput.

Hynek: Does this satisfy your notes in #4074-24?

Greg Shah wrote:

Hynek: Does this satisfy your notes in #4074-24?

Yes I'm sure Stanislav tested the mentioned use case in #4074-24.

Closing seems to be premature. I didn't implement Hynek's idea (I got confirmation only now). Should I implement it?

I have recently re-based 4231b where there is a revision regarding #4074-23. I converted AW recently and it seems like there is an issue with the fix. A short log is in #4440-8 (the AW reproducing steps are in #4440-1). Was the cause somehow considered in #4074-24 re-implementation? Or the new implementation has nothing to do with solving #4440-8?

Another aspect: due to #4074-30, is seems that the new implementation will be committed in 4335a anyway, so no hope for 4231b to be fixed?

Another aspect: due to #4074-30, is seems that the new implementation will be committed in 4335a anyway, so no hope for 4231b to be fixed?

This is my mistake. The improvement should go into 4231b with the original fix.