Printable View
Hi, on Ext.Net.WebForms 4.7.1 (but till at least 4.6.0) DirectEvents on TabPanels are not working.
I wrote a bug report at https://github.com/extnet/Ext.NET/issues/1611 that describes how to reproduce the issue, but meanwhile I would appreciate a workaround.
Any suggestions?
Maybe I'm missing something obvious?
Hello @Giacomo, and welcome to Ext.NET forums!
This small 'x' in the tabs you're using to close them is a handle from the TabPanel which goes thru the tab panel's remove() procedure, which physically removes the tab from the tab panel, ignoring the inner panels' closeMode setting.
So when the individual panels' close event is triggered, it has already detached any direct events from the component and it never triggers.
To avoid this, I'd suggest you dropping the Closable="true" behavior from the individual panels and switching over to a toolbar on the tabPanel with a 'close' button, that nicely handles the tabs' closing (and possible re-showing if they are not destroyed, like in the example you pointed). Something like this in the BottomBar section should just do:
Besides, for some time Ext JS has been emitting warnings (when run in debug mode) about the small 'x' not being accessibility-friendly (aria compliant).Code:<ext:Button runat="server" ID="CloseBtn" Handler="App.TabPanel1.closeTab(App.TabPanel1.getActiveTab())" Text="Close Active Tab" />
I hope this helps!
Thanks Fabricio!
I really appreciated your answer, but we have noticed that you added the issue as a defect to the next milestone, and we have decided to wait for an upstream fix.
Can you share an approximative date for the fix to go in production?
Hello @Giacomo!
We've indeed bound a milestone to the issue, but that's not necessarily next release. This issue might be a little too difficult to tackle with for the level of impact it has to the overall system.
That said, we unfortunately have no time frame at present to offer this issue fixed.
But for one sure thing, we'll post an update here as soon as the issue you reported gets fixed, as we mentioned the forum thread here in the issue.
This does not necessarily mean next release won't include the fix; it just means we can't say it will or will not be fixed in time.
Thanks for understanding.
Fine, thanks for your answer.
Unfortunately, the proposed solution cannot work for our customers / use cases due to strict UI/UX policy.
We are considering to move a large financial application from ExtNET 1.2 to your new ExtNET WebForms Classic.
The fact is that we obviously need to ponder the risks and the alternatives.
We prefer to stick to Ext.NET to retain the know-how, but honestly we did not expect this to be a complex issue affecting the overall system. Can you share some technical details? Can we help somehow with the refactoring?
As you might imagine, if we decide to stick with ExtNET, we are going to take a premium support, but in this early stage we cannot afford to take the wrong decision and regret it lately.
Hello again, @Giacomo!
We appreciate your interest and efforts on upgrading to Ext.NET 4 and we hope you deem it worth the effort!
For one thing, that can't be helped, we're talking about a 3-version-away upgrade, so there will be breaking changes between them. Especially between version 1 and 2, there were many structural changes. We thrive to keep the breaking changes to a minimum (or zero!) between minor version releases, but it is just not possible to do so between the major ones. Technology changes, and so we must follow.
We have some recent threads about other people upgrading their systems, and I believe from v2 to v4, with at least one reported success case. Usually the success reports comes mixed in with questions, so it is not really easy to dig out reports of success migration from version x to y; they come clear from inquiries like yours ("can I migrate from v1 to v4?") then probably tracking that person threads eventually elucidates the success throughout the migration.
This one should give you a good grasp of what expects you on upgrading the project: Upgrading to 4.1 with support for legacy 1.x, and the progress (without really a clue of when it was fully ported to v4, but that the project went fully to at least v4.5 at some point) from the posts history.
I'm sure if you further surf through the threads you'll get an even better overview of that.
Back to the main topic here, I understand you don't want to have the layout changed so much as to remove the little top-right 'x' close handle from the tabs. We still use this in our examples explorers too.
This seems to be enough to keep the layout you are using and allow the direct method to happen, just by wrapping away the tabstrip's close handle to the tab panel's closeTab() call. Just add the block below within your ext:TabPanel definition:
I hope this helps for now.Code:<TabBarConfig runat="server">
<CustomConfig>
<ext:ConfigItem Name="closeTab" Value="function(tabHandle) { return tabHandle.tabBar.tabPanel.closeTab(tabHandle.card); }" Mode="Raw" />
</CustomConfig>
</TabBarConfig>
Thanks a lot Fabricio, nice hack! It worked like a charm.