Extjs4.2 rtl is causing huge problems in IE6 - extjs

So recently me and the developer team I'm in have finished working on a huge project for transforming our entire system from Extjs2 to 4.2.
We have finished fixing everything, every little bug, except we were left with one little task, making the system also available for IE6 (many of our customers still use it). What we thought was a little task was apparently one big problem.
None of the grids were loaded properly (only column headers and no data), and many important components such as panels appeared blank.
We apply the rtl property in our main css file, since we don't want to add rtl: true for every component:
html { direction: rtl }
Once removing this, everything was working perfectly (except for the direction of course). Currently we are following the code in ext-all-rtl-debug and finding the problems one by one (for example we found out that an added cls in the mask function was causing some of the problems with the grid). As you can imagine, this is a big, painful and slow process (especially considering we debug ie6).
Although everything looks fine in FF, Chrome, and even IE7, the entire project have rendering problems in IE6.
If anyone is familiar with the issue, and perhaps know of a possible fix, we would be forever grateful!

The "rtl:true" config is inherited throughout the component hierarchy, you should be able to just add "rtl: true" to the top-level component in the hierarchy (usually the viewport). This eliminates any need to set "direction:rtl" yourself, since components in an rtl hierarchy will have the "x-rtl" class added to their element(s).
You also need to make sure you are using the rtl stylesheet, as Ext JS components require quite a bit of special styling to work correctly in rtl mode. For example, for the classic theme this would be: ext-theme-classic-all-rtl.css
If you're still stuck, have a look at this example: http://docs.sencha.com/extjs/4.2.1/extjs-build/examples/rtl/rtl.html?theme=classic

Related

setLeadComponet leading to a sluggish UI

I have noticed that all my setLeadComponent calls are leading to a sluggish UI when scrolling up or down. It used to work perfectly in the past so I guess a recent platform update may have messed it up.
My use case requires me to create a list of items that users can scroll through and click on items. I have adopted the approach discussed in the 'Avoiding Lists' article.
Any pointers on what may be causing this?
PS: I am currently exploring using addPointerReleasedListener() as an alternative.
This can be a couple of things described by these two issues. First it could be similar to the bug described here.
It also could be due to this, which was eventually resolved via by disabling layout on paint (which is now the default). It might make sense to re-enable layout on paint in the parent form to see if this solves your issue.

Foundation Framework and React - reInit accordion not working

Problem
I call setState to add a new recipe to my recipe list
The recipe is a new panel in a Foundation accordion
The accordion title pops up immediately
There is no functionality until page refresh
I have tried everything i can think of including Foundation's reInit, their manual toggle, up, and down methods for accordions, and re constructing the whole accordion
nothing works
This is the solution I came up with.
i was able to call $("#element").foundation("toggle",$target,true) from the console and programmatically open and shut the accordion tab.
element is the accordion wrapper and target the specific tab, true is a param to indicate reflow needed
implementing that function into my app was more trouble than it was worth, for a number of reasons.
i ended up just calling location.reload() and which essentially is like pressing the refresh button. with a modal animation running at the same time it is barely noticeable
so when all else fails manual over-ride could be a viable solution depending on what your individual page is
There is a real answer
in my research i came across quite a few similar github issues that had to do with Foundation plus some sort of dynamic rendering and/or third party framework/library. every situation is a bit different so there isn't one answer
if someone has specific knowledge of what why Foundation or React(possibly), wouldn't let me reInit,reflow,$(document).foundation or do any of the various supposed solutions: I would love to know.
perhaps I could have done something different but if you look at my code I keep state to one component, I init my js plugins in componentDidMount - as far as i know this is what i am supposed to do. thanks

Angular transition area below collapsing up against navigation

I am very new to all things Angular and have been experimenting with some stuff.
Been playing with UI-Router and with Angular Animations.
So far everything is going to plan, except one thing.
During the transition between pages (my top-most states) the footer area collapses up under the main content and against the navigation.
(I'm also fairly new to css transitions, so my knowledge is limited, but growing)
Is there anything that can be done to prevent this from happening? Maybe have it snag on to the height of whichever state is the tallest? (IE, the one leaving, or the one entering)
(I've tried searching everywhere, but whatever I search for I come up dry. Maybe I'm searching the wrong keywords.)
I have included a plnkr link
Thanks in advanced.

Outdated UI automation tree

I am trying programming an automated tester application using the new native Microsoft UI Automation interface 3.0 (in VC++ 2010, Win7). The Application Under Test (AUT) is a WPF application.
Almost everything works fine... I can install event handlers, navigate through the tree, search elements using various conditions and control the found elements using their patterns.
But yesterday I found a behaviour that leaves me despaired: The UIA tree of my AUT simply is not updated after switching its GUI main panel by clicking one of its main menu buttons.
After clicking the main menu button, I can see the new widgets in the AUT's GUI but the UIA tree still contains the controls that have been there before clicking the main menu button. The (outdated) UIA tree can be still completely read using search functions or using walker but of course it can not be written since the widgets do not exist anymore.
This exactly looks like there would be an outdated cache... however I do NOT use any caching UIA functions at all. None. Never. Nowhere.
I was not able to make the UIA tree update programatically... neither by calling any UIA functions nor by restarting the tester application nor by switching the AUT's GUI back and forth.
This does not happen every time. Sometimes after clicking the main button the tree seems properly up-to-date and everything works fine. However most of the runs it fails.
There is only one (mysterious) way that updates the UIA tree reliably: Using inspect.exe. When using inspect.exe tool for having a brief look into the AUT's UIA sub tree, the problem is suddenly gone and my tester application can access the actual, updated tree immediately! Of course the problem re-appears after restarting the AUT.
What does inspect.exe do to make the UIA tree (of another application!!!) update? How is it possible at all to access gone elements without using any caching? What did I miss?
I really need help.
Ok, some more findings:
UISpy.exe is able to refresh the UIA tree the same mysterious way inspect.exe does (this is especially strange because inspect.exe uses the same native interface as I do but UISpy.exe uses the .NET interface AFAIK). This means this is a kind of system wide and persistent UIA problem and not a pure native-UIA-problem.
The problem does not happend if I do not access the tree before switching the view. I.e. if my tester application does not access the AUT'S view before switching the view by clicking the main menu button, it sees the new widgets without problems. This strongly indicates some caching problem of the native UIA API - even if I have no idea how this could happen because I do not caching at all. Does someone know if there is some internal caching taking place?
I think this could be a API bug. However considering my current experiences with Microsoft Connect I am kind of lost with that showstopper :-(
Someone any idea?
I also tested the Snoop tool. Using Snoop does NOT heal the problem temporarily like Inspect and UISpy do. Regarding Inspect.exe, there is another detail... it is enough to collapse and expands the AUT's sub-tree to temporarily heal the problem.
Ok, update on this. UIA simply seems horribly buggy. I found that reading an element's content array and the length of that array updates the hidden caches. I also had a case where a subtree of a tab was not update but could be updated by switching to another tab and back (reading the content by pattern did NOT help in that case). Both cases were reproducable but I could not find any way to predict or prevent them. Also al lot of third party WPF components seem to be buggy. We finally gave up to use that API.
I know the question is quite old but I figured out what Inspect.exe does to refresh the UIA tree for other applications: look at the Options menu; there's an item labeled SPI_SCREENREADER flag which is checked by default.
Do the following in your code and you will probably get a fresh UIA tree:
SystemParametersInfo( SPI_SETSCREENREADER, TRUE, NULL, SPIF_UPDATEINIFILE | SPIF_SENDCHANGE);
PostMessage( HWND_BROADCAST, WM_WININICHANGE, SPI_SETSCREENREADER, 0);

Is a drag-over checkbox list useful?

A while ago I created a drag-over check box list which allows you to check many check boxes in a single gesture. Do you think it is viable and usable on the web where people might not know how to use it. The default behaviour still works for the individual check boxes.
1 - The idea
The idea is nice and can probably be used in professional applications where you have direct contact with users and can explain them how things work, but not necessarily on public websites where users don't want to RTFM and are just looking for familiar behaviours. Unless it was just a sample exercise or a control meant to be included it in a control pack, it violates the YAGNI principle ;)
2 - The implementation
You certainly noticed that the implementation is buggy (at least on IE7 and FF3.1B2). Sometimes, a gesture above all checkboxes will select all of them but one or two. Moving the mouse over the div's above or below the list will stop the drag (I know it's a "feature", but it's not very user friendly). I Checked the source code and to be honnest, while it looks pretty neat, I just didn't want to deal with it because it is plain javascript. Don't you know that...
3 - Possible improvements
...you can write less and do more with a javascript library, typically jQuery. I would completely rewrite this control as a jQuery plugin. It will provide you with a lot of tools to make your code much easier to write, maintain and extend. Just try it, you'll love it. This is from a technical point of view. From a user point of view, try to make you control as familiar as possible, like what Angela suggested, windows explorer : a nice selection rectangle, the ability to use shit + click, or something like that. Finally, remember that for many windows checklistbox users, "selected" and "checked" are two different things.
The demo definitely needs a few enhancements to make it even a little bit useful (although I am not sure if it would be enough):
Allow the dragging to start somewhere that is not a check box.
Allow selection by dragging over the labels as well.
This problem seems similar to the action of selecting multiple files in a file explorer like Windows Explorer. Maybe it can work like the action of selecting multiple files by dragging a rectangle shape around the items to be selected (select one corner, drag to the other corner)? This has the advantage of being similar to an interface element that people may already be familiar with.
For some reason I can't open your link (it says my ip address was blocked). But I think what you're looking for is what I already did in jquery, I uploaded a plugin which I basically ported from crossbrowser.com's dragcheck functionality, it was to be found at http://plugins.jquery.com/project/dragCheck but currently the jquery plugin site is being revamped and my plugin has disappeared. I'm trying to see if they're going to put it back up or if I have to create a new project again...
Anyways until we get that worked out you can see a demo here: http://jsbin.com/ibihi

Resources