From: "Eric Bezault" To: Cc: Subject: RE: EiffelVision_2/4042 Date: Sun, 19 Sep 2004 07:38:31 -0700 > 2) When the focus is in the text field and I click on the > arrow box the EV_COMBO_BOX loses the focus. The agents registered in: > > my_combo_box.focus_out_actions > > are executed. This does not seem right to me. If it was a > design decision to make EV_COMBO_BOX an atomic widget and not > provide access to its text field and box subcomponents then > the focus should not have been lost when clicking on the arrow box. My workaround has been to add the following routine in a descendant of EV_COMBO_BOX: has_box_focus: BOOLEAN is -- Is the focus on the box part of the combo box? -- (`has_focus' returns true only if the focus is on the text field part!) local l_combo_box_imp: EV_COMBO_BOX_IMP do l_combo_box_imp ?= implementation if l_combo_box_imp /= Void then Result := l_combo_box_imp.combo.has_focus end end and then call both `has_focus' and `has_box_focus' in order to figure out whether the EV_COMBO_BOX really lost the focus or not. But this is just a workaround for my particular needs and I would prefer all these problems with EV_COMBO_BOX to be seriously addressed in EiffelVision2. -- Eric Bezault From: "Eric Bezault" To: Cc: Subject: RE: EiffelVision_2/4042 Date: Mon, 20 Sep 2004 05:29:51 -0700 > -----Original Message----- > From: Eric Bezault > Sent: Sunday, September 19, 2004 7:39 AM > To: 'bugs@berkeley.eiffel.com' > Subject: RE: EiffelVision_2/4042 EV_COMBO_BOX does not work > as expected > > > > 2) When the focus is in the text field and I click on the > > arrow box the EV_COMBO_BOX loses the focus. The agents > registered in: > > > > my_combo_box.focus_out_actions > > > > are executed. This does not seem right to me. If it was a > > design decision to make EV_COMBO_BOX an atomic widget and not > > provide access to its text field and box subcomponents then > > the focus should not have been lost when clicking on the arrow box. > > My workaround has been to add the following routine in a descendant > of EV_COMBO_BOX: > > has_box_focus: BOOLEAN is > -- Is the focus on the box part of the > combo box? > -- (`has_focus' returns true only if > the focus is on the text field part!) > local > l_combo_box_imp: EV_COMBO_BOX_IMP > do > l_combo_box_imp ?= implementation > if l_combo_box_imp /= Void then > Result := > l_combo_box_imp.combo.has_focus > end > end > > and then call both `has_focus' and `has_box_focus' in order to > figure out whether the EV_COMBO_BOX really lost the focus or not. > > But this is just a workaround for my particular needs and I would > prefer all these problems with EV_COMBO_BOX to be seriously addressed > in EiffelVision2. Note that I would be happy if EV_COMBO_BOX.has_focus would be an "or" between the current result of `has_focus' and the result of `has_box_focus' above (and then be able to get rid of `has_box_focus'). -- Eric Bezault State-Changed-From-To: open-analyzed State-Changed-By: Manu State-Changed-When: Mon Sep 20 11:20:58 PDT 2004 State-Changed-Why: Dear Eric, We fixed 1 and 2. However for 3 and 4, Windows does not help much in achieving what you would like to achieve because Windows combo boxes are made of actually 2 or 3 widgets (depending if the combo box is editable or not). Could you describe us why do you need to call `enable_capture' on the combo box? From: "Eric Bezault" To: "ISE Customer Support" Cc: Subject: RE: EiffelVision_2/4042 Date: Mon, 20 Sep 2004 12:21:18 -0700 Hi Manu, > Could you describe us why do you need to call `enable_capture' on the > combo box? This is related to the last paragraph of my bug report. I want to be notified when the combo box loses the focus, but also when the user clicks somewhere else (even if the combo box does not lose the focus, which is the case when that "somewhere else" is a label for example). So I don't really need `enable_capture'. It's just that EV_COMBO_BOX was so broken that I tried everything I could in order to find workarounds. I don't really need `enable_capture', but I'm nevertheless interested in your advice about the last paragraph of my bug report: ~~~~~~ BTW, is there a way to know if the mouse has been clicked somewhere? With `enable_capture' we can monitor the actions executed in `pointer_button_press_actions' for example. But what I want is the mouse click to perform its normal behavior (even in other widgets, so `enable_capture' does not work quite well here) but be notified of such click. Adding an agent in `pointer_button_press_actions' of all widgets of my application is quite cumbersome. Is there a better way? ~~~~~~ While I'm seeking for advice, here is another message that I sent to Julian. Just in case you have a suggestion. ~~~~~~ With WEL I was calling `disable_default_processing' in my `on_...' routines if I wanted to forbid the default behavior. Is there an equivalent of this routine in EiffelVision2 that we could call when executing agents registered for some events? I saw that the EV_..._IMP classes are calling `disable_default_processing', but I didn't figure out how to achieve the same thing from the Vision2 interface classes. ~~~~~~ Thank you. -- Eric Bezault From: "Eric Bezault" To: "ISE Customer Support" Cc: Subject: RE: EiffelVision_2/4042 Date: Mon, 20 Sep 2004 13:55:52 -0700 > We fixed 1 and 2. Is there a patch that I can use for EV_COMBO_BOX or EV_COMBO_BOX_IMP (just to be sure that I get the same behavior when you'll send us the next version)? -- Eric Bezault State-Changed-From-To: analyzed-analyzed State-Changed-By: Manu State-Changed-When: Mon Sep 20 14:27:20 PDT 2004 State-Changed-Why: Dear Eric, For the question: " BTW, is there a way to know if the mouse has been clicked somewhere?", I'm afraid that I don't have a nice solution apart adding your action to all widgets. Now why do you need to know that the user clicked outside the combo box (especially now that the focus-out actions should be called correctly with the previous fix)? For the second question, the answer is no too. There is no routine that you can add to the action sequences that would prevent the default processing on Windows. The issue is that most of the time we don't know what the default processing is and we only disabled it when we know its effects to ensure a certain behavior that will be the same on GTK and Win32. Again, any particular example of things that you would like to disable? We could possibly add what you want differently. From: "Eric Bezault" To: "ISE Customer Support" Cc: Subject: RE: EiffelVision_2/4042 Date: Mon, 20 Sep 2004 14:56:56 -0700 > For the question: " BTW, is there a way to know if the mouse > has been clicked somewhere?", I'm afraid that I don't have a > nice solution apart > adding your action to all widgets. Now why do you need to know that > the user clicked outside the combo box (especially now that the > focus-out actions should be called correctly with the previous fix)? The reply was in my previous message. I want to know whether the user clicked somewhere else (meaning that he lost interest in editing the combo box) even when the combo box does not lose the focus (which is the case when that "somewhere else" is a label for example: the label does not take the focus when we click on it). Is there a way to get the list of widgets (I know that we can get the list of windows from EV_APPLICATION) or should I traverse them "by hand" top to bottom one by one? > For the second question, the answer is no too. There is no routine > that you can add to the action sequences that would prevent the > default processing on Windows. The issue is that most of the time we > don't know what the default processing is and we only disabled it > when we know its effects to ensure a certain behavior that will be > the same on GTK and Win32. Again, any particular example of > things that > you would like to disable? We could possibly add what you > want differently. In the combo box, when I hit Return my agent registered for my_combo_box.return_actions gets executed. If during this execution I find out that the text entered is invalid, then I report an error message and I call my_combo_box.select_all. But if I don't call `disable_default_processing' the text never gets selected and the caret is moved to the first position of the text field, which is very inconvenient because it forces the user to move the caret back to where it was. When calling `disable_default_processing' I don't have this problem. -- Eric Bezault State-Changed-From-To: analyzed-analyzed State-Changed-By: Manu State-Changed-When: Mon Sep 20 21:58:44 PDT 2004 State-Changed-Why: Dear Eric, For problem #1, we can only suggest to try a different alternative to find out when the user has lost interest in the content of the combo box. The alternative seems: - loosing focus (but not good enough from what you want) - make this explicit (adding some buttons so that the user can let the program know he doesn't care anymore about the combo) - add the action to all widgets using the technic you mentioned (we do not have such a feature yet) For the problem #2, I believe this is a bug in our code. Remove the redefinition of `on_cben_endedit_item' from EV_COMBO_BOX_IMP and it should work just fine with the return_actions. There seems to be no particular reason why it is there and we are thinking of removing it for the next release unless we find something that really requires it. From: "Eric Bezault" To: "ISE Customer Support" Cc: Subject: RE: EiffelVision_2/4042 Date: Tue, 21 Sep 2004 12:54:46 -0700 > For the problem #2, I believe this is a bug in our code. Remove the > redefinition of `on_cben_endedit_item' from EV_COMBO_BOX_IMP and it > should work just fine with the return_actions. Yes, it works. > There seems to be no > particular reason why it is there and we are thinking of removing it > for the next release That would be great. > unless we find something that really requires it. There is this behavior in EiffelStudio, but you can easily add an agent in `return_actions' which does that for you. -- Eric Bezault