Manual autofitting (from the header button menus) is controlled by LGF.canAutoFitWidth for a field, and ListGrid.canAutoFitFields for the whole ListGrid. Automatic, continuing autofitting is controlled by LGF.autoFitWidth for a field, and ListGrid.autoFitFieldWidths for the whole ListGrid.
Originally, we were setting autoFitWidth:true by default on the remove field, so that it was automatically autofitting even if the grid wasn't configured for autofitting. We removed that default in the original fix, so that then, the remove field would only autofit if the entire grid were configured for autofitting (via autoFitFieldWidths: true).
The recent fix was to add autoFitWidth: false and canAutoFitWidth: false to the field defaults for the remove field, so that, first, it won't autofit even if the grid is configured for automatic autofitting, and second, it cannot be manually autofit from the grid header, either on the field itself or by selecting "AutoFit All Columns."
Announcement
Collapse
No announcement yet.
X
-
Hi Isomorphic,
this is fixed for me using v11.1p_2017-08-20.
Can you explain what that attribute is? I had trouble understanding this before.Originally posted by Isomorphic View PostThe fix reported in post #4 prevented an automatic autofit from being enabled by default for the remove field if it wasn't set for the ListGrid as a whole. It wouldn't have disabled the automatic autofit for that field if it was enabled for the ListGrid as a whole - that's what we've done now. We've also disabled the remove field from participating in a manual autofit triggered by the ListGrid header menus - that's controlled by a separate attribute.- it's not canAutoFitWidth - this is for manual autofitting via the header menu and definitely disabled now.
- it's not autoFitWidth - this is for ongoing column resizing depending on the content of the ListGrid
- perhaps it is not passed to ListGrid.autoFitFields() on initial ListGrid display?
- or am I missing some API?
Blama
Leave a comment:
-
The field mismatch problem you mention has been fixed back to SGWT 4.1p/SC 9.1p.Originally posted by Blama View PostHi Isomorphic,
now testing with v11.1p_2017-08-16.[LIST][*]Calling autoFitAllFields from the menu assigns the extra space to the removeField, not the setAutoFitExpandField("MaritalStatus"). This goes away if you comment out setShowRowNumbers(true).
We agree it makes little sense to support autofit or drag-resizing by default for the remove field, so we've made the changes you suggest back to SC 10.1p.Originally posted by Blama View Post- The removeField takes part in autoFit by default, unlike the rowNumberField, I don't think this is on purpose. This fixes it:
Code:ListGridField removeProperties = new ListGridField("remove"); removeProperties.setCanAutoFitWidth(false); employeesGrid.setRemoveFieldProperties(removeProperties); - The removeField in resizeable by default, unlike the rowNumberField, I don't think this is on purpose. This fixes it:
Code:ListGridField removeProperties = new ListGridField("remove"); removeProperties.setCanDragResize(false); employeesGrid.setRemoveFieldProperties(removeProperties);
Best regards
Blama
The fix reported in post #4 prevented an automatic autofit from being enabled by default for the remove field if it wasn't set for the ListGrid as a whole. It wouldn't have disabled the automatic autofit for that field if it was enabled for the ListGrid as a whole - that's what we've done now. We've also disabled the remove field from participating in a manual autofit triggered by the ListGrid header menus - that's controlled by a separate attribute.Originally posted by Blama View Post
That should have fixed my issue 2 from #5, but did not.
Best regards
Blama
All of the above changes should be in the nightly builds dated 2017-08-20 and beyond.
Leave a comment:
- The removeField takes part in autoFit by default, unlike the rowNumberField, I don't think this is on purpose. This fixes it:
-
That should have fixed my issue 2 from #5, but did not.Originally posted by Isomorphic View PostYour issue specifically with the "remove record" field was caused by it being internally configured to autofit, which made it always subject to ListGrid.minFieldWidth, even if it had a fixed width already set. This has been fixed back to SGWT 6.0p and will be in the nightly builds dated 2017-04-20 and beyond.
Best regards
Blama
Leave a comment:
-
Hi Isomorphic,
now testing with v11.1p_2017-08-16.- Calling autoFitAllFields from the menu assigns the extra space to the removeField, not the setAutoFitExpandField("MaritalStatus"). This goes away if you comment out setShowRowNumbers(true).
- This is an off-by-one when using setShowRowNumbers(true). Using that, setAutoFitExpandField("OrgUnit") makes MaritalStatus the autoFitExpand-field.
- The removeField takes part in autoFit by default, unlike the rowNumberField, I don't think this is on purpose. This fixes it:
Code:ListGridField removeProperties = new ListGridField("remove"); removeProperties.setCanAutoFitWidth(false); employeesGrid.setRemoveFieldProperties(removeProperties); - The removeField in resizeable by default, unlike the rowNumberField, I don't think this is on purpose. This fixes it:
Code:ListGridField removeProperties = new ListGridField("remove"); removeProperties.setCanDragResize(false); employeesGrid.setRemoveFieldProperties(removeProperties);
Blama
Leave a comment:
- Calling autoFitAllFields from the menu assigns the extra space to the removeField, not the setAutoFitExpandField("MaritalStatus"). This goes away if you comment out setShowRowNumbers(true).
-
Your issue specifically with the "remove record" field was caused by it being internally configured to autofit, which made it always subject to ListGrid.minFieldWidth, even if it had a fixed width already set. This has been fixed back to SGWT 6.0p and will be in the nightly builds dated 2017-04-20 and beyond.
The other behavior you describe, such as the minFieldWidth being applied to all fields during a manual autofit, or the ListGrid overflowing horizontally creating a scrollbar during a manual autofit, are both by design, and have been in place for many releases.
Leave a comment:
-
Hi Isomorphic,
yes, see this BuiltInDS based sample (SNAPSHOT_v11.1d_2017-04-14):
There are a few things to notice:Code:package com.smartgwt.sample.client; import com.google.gwt.core.client.EntryPoint; import com.smartgwt.client.Version; import com.smartgwt.client.core.KeyIdentifier; import com.smartgwt.client.data.AdvancedCriteria; import com.smartgwt.client.data.Criterion; import com.smartgwt.client.data.DataSource; import com.smartgwt.client.data.SortSpecifier; import com.smartgwt.client.types.Autofit; import com.smartgwt.client.types.OperatorId; import com.smartgwt.client.types.SortDirection; import com.smartgwt.client.util.Page; import com.smartgwt.client.util.PageKeyHandler; import com.smartgwt.client.util.SC; import com.smartgwt.client.widgets.IButton; import com.smartgwt.client.widgets.Window; import com.smartgwt.client.widgets.events.ClickEvent; import com.smartgwt.client.widgets.events.ClickHandler; import com.smartgwt.client.widgets.form.fields.ComboBoxItem; import com.smartgwt.client.widgets.grid.ListGrid; import com.smartgwt.client.widgets.grid.ListGridField; import com.smartgwt.client.widgets.layout.VLayout; public class BuiltInDS implements EntryPoint { private VLayout mainLayout; private IButton recreateBtn; public void onModuleLoad() { KeyIdentifier debugKey = new KeyIdentifier(); debugKey.setCtrlKey(true); debugKey.setKeyName("D"); Page.registerKey(debugKey, new PageKeyHandler() { public void execute(String keyName) { SC.showConsole(); } }); mainLayout = new VLayout(20); mainLayout.setWidth100(); mainLayout.setHeight100(); recreateBtn = new IButton("Recreate"); recreateBtn.addClickHandler(new ClickHandler() { @Override public void onClick(ClickEvent event) { recreate(); } }); mainLayout.addMember(recreateBtn); recreate(); mainLayout.draw(); } private void recreate() { Window w = new Window(); w.setWidth("95%"); w.setHeight("95%"); w.setMembersMargin(0); w.setModalMaskOpacity(70); w.setTitle(" (" + Version.getVersion() + "/" + Version.getSCVersionNumber() + ")"); w.setTitle("TITLE" + w.getTitle()); w.setShowMinimizeButton(false); w.setIsModal(true); w.setShowModalMask(true); w.centerInPage(); w.setCanDragResize(true); final ListGrid employeesGrid = new ListGrid(); employeesGrid.setHeight100(); employeesGrid.setAutoFetchData(false); employeesGrid.setDataSource(DataSource.get("employees")); employeesGrid.setCanGroupBy(false); employeesGrid.setShowRecordComponents(false); employeesGrid.setShowRecordComponentsByCell(false); employeesGrid.setAutoFitExpandField("MaritalStatus"); employeesGrid.setMinFieldWidth(100); employeesGrid.setCanRemoveRecords(true); employeesGrid.setShowRowNumbers(true); ListGridField employeeId = new ListGridField("EmployeeId"); ListGridField name = new ListGridField("Name"); ListGridField gender = new ListGridField("Gender"); ListGridField reportsTo = new ListGridFieldReportsTo("ReportsTo"); ListGridField job = new ListGridField("Job"); ListGridField email = new ListGridField("Email"); ListGridField employeeType = new ListGridField("EmployeeType"); ListGridField employeeStatus = new ListGridField("EmployeeStatus"); ListGridField salary = new ListGridField("Salary"); ListGridField orgUnit = new ListGridField("OrgUnit"); ListGridField maritalStatus = new ListGridField("MaritalStatus"); employeesGrid.setFields(employeeId, name, gender, reportsTo, job, email, employeeType, employeeStatus, salary, orgUnit, maritalStatus); employeesGrid.setSort(new SortSpecifier[] { new SortSpecifier(name.getName(), SortDirection.ASCENDING) }); employeesGrid.fetchData(new AdvancedCriteria(new Criterion(name.getName(), OperatorId.STARTS_WITH, "A"))); w.addItem(employeesGrid); w.show(); } private class ListGridFieldReportsTo extends ListGridField { public ListGridFieldReportsTo(String name) { super(name); ComboBoxItem managerCBI = new ComboBoxItem(); managerCBI.setOptionDataSource(DataSource.get("employees")); managerCBI.setOptionOperationId("foobar"); managerCBI.setValueField(DataSource.get("employees").getPrimaryKeyFieldName()); managerCBI.setDisplayField("Name"); managerCBI.setPickListSort(new SortSpecifier[] { new SortSpecifier("EmployeeId", SortDirection.ASCENDING), new SortSpecifier("Name", SortDirection.ASCENDING) }); ListGridField managerCBI_empIdLGF = new ListGridField("EmployeeId"); ListGridField managerCBI_nameLGF = new ListGridField("Name"); managerCBI.setPickListFields(managerCBI_empIdLGF, managerCBI_nameLGF); managerCBI.setPickListHeaderHeight(0); setEditorProperties(managerCBI); } } }- The removeRecord field is too wide as described in the original post.
- Starting from employeesGrid.setMinFieldWidth(25) there is always a horizontal scrollbar, as (my guess) the ListGrid wants to leave less space for the removeField, sizes the other fields accordingly and then has to introduce the scrollbar in order to add the wider-than-expected removeField.
- Calling autoAitAllFields from the menu assigns the extra space to the removeField, not the setAutoFitExpandField("MaritalStatus"). This goes away if you comment out setShowRowNumbers(true).
- The removeField is resizeable by default, unlike the rowNumberField.
Blama
Leave a comment:
-
Are you seeing a problem with the initial draw of the grid, or trying to use autofit? We're not seeing any issue like what you claim unless autofit is used.
Can you provide the complete sample code?
Leave a comment:
-
ListGrid.setMinFieldWidth(50) and removeField-width
Hi Isomorphic,
using 6.1d, is there a way using ListGrid.setMinFieldWidth(50) and at the same time keeping generated fields like the removeField for setCanRemoveRecords(true) or the rowNumberField for setShowRowNumbers(true) at their normal sizes?
This does not work for me, the width is 50 anyway.
Perhaps the method that checks the minFieldWidth should exclude those two fields?Code:ListGrid lg = new ListGrid() { { setMinFieldWidth(50); setRemoveFieldProperties(new ListGridField() { { setWidth(24); } }); } }; ListGrid.setDefaultProperties(lg);
Thank you & Best regards
BlamaTags: None
Leave a comment: