Hi,
My toolbar is disappearing when I use the tab key to advance through a txt type field in a grid.
I am including sample data and my code with notation for the version of each javascript.
To replicate, double click the first cell in the row to enter it, then use the tab key twice to enter the second field and then the third, both of which are type txt. My experience is that the toolbar disappears with the second click of the tab key as I move from the second to third field.
Much appreciate your help with this. It is killing me with the POC test team.
Thanks,
Max
---- data sample begins here ----
<?xml version="1.0" encoding="UTF-8" ?>
---- code sample begins here ----
Explore OONdada Compliance and Audit Accelerator
Unfortunately we cannot reproduce this issue locally. Please try to replace all of attached files from the latest 2.1 version. Standard package you can download here dhtmlx.com/docs/download.shtml.
If issue still occur please send us full example including all files which you are using to initialize components.
Hello,
the issue is confirmed. We’ll send you the fix when it is ready.
The issue will be fixed in the next layout version.
Could you please provide us the information about the doctype that you use ? So, we’ll be able to solve the issue specially for this doctype - as in the current version the universal solution will be rather complicated.
Great to hear you found it. The doctype we are using is the same as the sample code:
Thanks,
Max
Hey Guys, just checking in. Will you be able to hook me up with a quick fix for this one? That would be very much appreciated.
And thanks for the great support.
Max
Hello Max,
we have attached the sample with fixed files: dhtmlxlayout.js, dhtmlxwindows_wtb.js and dhtmlxwindows.js
58.zip (147 KB)
Hey, really great response and the initial issue has been resolved. Tabbing no longer kills the toolbar.
There is, however, a new (hopefully trivial) issue that has emerged.
After we applied the QFE patch, a mystery field has appeared immediately to the left of our centered main container div and immediately below our header div. The only other div on the page is the parentID div for the main layout that frames everything else that appears in the app. It appears that the field is somehow associated with dhtmlxwindows.js as it appears immediately after that step of the patch is applied.
The field is active, accepts text entry, and appears to be approxiimately 145px in fixed width. It floats underneath the applications main container div when the browser window is resized.
My hope is that this is simply a hack that someone forgot to remove from th QFE, perhaps related to sizing or something???
Anyway, other than leveraging it somehow for a uniquely located login field, we really don’t need it. Anything you can do to make it go away would be greatly appreciated!!!
I am attaching the bug report text and code samples.
Thanks and, again, really great support and response. We really value your efforts as we try to get this POC completed and our site launched. We are working 16 hr days and I can’t tell you how much it helps to know that issues with these controls are quickly and reliably resolved. You guys deserve a special place in open source heaven.
Max
mystery_field_dhtmlx_qfe_tab_breaks_toolbar.zip (148 KB)
Also attaching the full QFE test page that we used to isolate the behavior.
Thx
qfe-tab-breaks-toolbar.php.zip (993 Bytes)
Hello,
the issue wasn’t reproduced locally - please, take a look at the attached sample.
The only problem, that we have got, is that in Opera layout isn’t shown with position:absolute;
So, we have replaced it with relative:
58_new.zip (136 KB)
Hey Alex, just to let you know, we have closed this ticket. We have updated all javascript to 2.1 today, eliminating the previous mix of versions, and the problem of the mystery field went away. Much appreciate your team putting the QFE together so quickly. This was a major issue with our POC users and they are now much happier.
Thanks again,
Max