Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    ComboBox - unexpected EditorExitEvents in recent night-builds

    I have a bit sophisticated ComboBoxItem with GWT-DataSource and some important code in EditorExitHandler. When GWT-DataSource is loading data from server I am covering screen by modal-masked ProgressBar window.
    This construction has 3 advantages:
    1) User can see, that loading of data is in progress (same progressBar in all loading-situations of the application)
    2) Even with progressBar on the screen, user still can continue in typing of letters into ComboBox
    3) User can not change any other formItem, while loading and related code is not finished. In this case it's important, because of functionality in EditorExitHandler, too.

    In some of recent night-builds SmartGwt changed behaviour. Now the ComboBoxItem gets EditorExitEvent every time, when the progressBar-window is shown and besides this user can not continue in typing into ComboBox. Even more - I don't know how to distinguish between EditorExitEvent as intention of user and EditorExitEvent caused by showing progressBar window.

    Is it possible to revert to previous functionality?

    In last production version of SmartGwt and at least up to SmartGWT 5.1d (Tue Jan 27 11:40:00 CET 2015) everything worked fine.

    I made for you some simplified code (you can use new and old SmartGwt to see the difference):
    Code:
    	@Override
    	public void onModuleLoad()
    	{
    		final Window progressWnd = createWindowInstance();
    		final StaticTextItem infoText = new StaticTextItem("editorExit", "editorExit");
    		infoText.setValue("-");
    		
    		// TEST CASE:
    		ComboBoxItem combo = new ComboBoxItem("combo", "combo");
    		combo.setValueMap("1", "2");
    		combo.addEditorExitHandler(new EditorExitHandler()	
    		{
    			@Override
    			public void onEditorExit(EditorExitEvent aEvent)
    			{
    				infoText.setValue((String)infoText.getValue() + " EditorExit!");
    			}
    		});
    		combo.addChangedHandler(new ChangedHandler()
    		{
    			@Override
    			public void onChanged(ChangedEvent aEvent)
    			{
    				progressWnd.show();
    				Timer timer = new Timer()
    				{
    					@Override
    					public void run()
    					{
    						progressWnd.hide();
    					}
    				};
    				timer.schedule(3000);
    			}
    		});
    	    
    		// form
    		final DynamicForm form = new DynamicForm();
    		form.setItems(combo, infoText);
    
    		// GWT / SmartGwt versions
    		String versionString = "Versions: "
    				+ "GWT " + GWT.getVersion()
    				+ ", SmartGWT " + Version.getVersion() 
    				+ " (" + Version.getBuildDate() + ")";
    		Label gwtVersion =  new Label(versionString);
    		System.out.println(versionString);
    
    		// layout + draw
    		VLayout layout = new VLayout();
    		layout.setWidth100();
    		layout.setMembers(gwtVersion, form);
    		layout.draw();
    	}
    	
    	private static Window createWindowInstance()
    	{
    		Progressbar progressbar = new Progressbar();
    		
    		Window result = new Window();
    		result.addItem(progressbar);
    		
    		result.setTitle("");
    		result.setStyleName("");
    		result.setWidth(300);
    		result.setHeight(40);
    		result.setOverflow(Overflow.HIDDEN);
    		result.setBorder("0px");
    		
    		result.setShowCloseButton(Boolean.FALSE);
    		result.setShowMinimizeButton(Boolean.FALSE);
    		result.setShowMaximizeButton(Boolean.FALSE);
    		
    		result.setShowBody(Boolean.TRUE);
    		result.setShowHeader(Boolean.FALSE);
    		result.setShowTitle(Boolean.FALSE);
    		
    		result.setAutoCenter(Boolean.TRUE);
    		result.setCanDragReposition(Boolean.FALSE);
    		result.setCanDragResize(Boolean.FALSE);
    
    		result.setShowModalMask(Boolean.TRUE);
    		result.setModalMaskOpacity(25);
    		result.setIsModal(Boolean.TRUE);
    		
    		return result;
    	}

    #2
    Actually it looks like your existing construction was relying on a framework bug which we have recently fixed.
    When a clickMask is shown, all user interaction with components which are "masked" is supposed to be suppressed. This includes taking focus from the current focus target if it is masked and excluding it from the page's tab order as long as the mask is up.
    The modal window uses the click mask to ensure its modality.

    As such, showing a modal window would be expected to take focus from the current focus target (your ComboBoxItem) -- and when focus is taken away, the editor-exit handler will fire.

    We had an issue where in some cases the modal mask would fail to take focus from the currently focused widget which has recently been resolved and is leading to the problem you're seeing.

    We don't really have a built-in solution to do exactly what you describe -- mask the entire page, including an item, but continue to allow typing within that masked item if focus is already there. Our initial inclination here would be that you might want to consider reworking the UI: Show the progress-bar in an appropriate spot, perhaps, but don't embed it in a modal window, so the user can continue to interact with the app while the progress bar is visible.

    You could of course roll your own "mask" by showing a canvas over the entire page with a tint (an opacity of ~20 plus backgroundColor being set to black, for example), and use 'bringToFront' to move the progressbar above it, but it's not clear to us that this is a particularly intuitive UI.

    Regards
    Isomorphic Software

    Comment

    Working...
    X