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.
Related
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
My WPF application has a number of "pop-up" dialogs. There's no real need to show them on the task bar. Problem is that by turning off "ShowInTaskBar", they can be minimized to what I think is a somewhat unconventional representation (just above the taskbar), and as such can be inadvertently pushed down in z-order behind the "parent" or other windows, thus seemingly disappearing, but still deactivating the parent while open. There's no real need to minimize them anyway (user might as well just close/cancel), so I think it would make sense to disable minimize functionality for the "pop-up" windows. What would be the most straightforward way to do that (still allow resize/maximize/restore)? As best I recall, this was no big deal in "old-fashioned" Win32/MFC/Winforms - either a checkbox setting to disable the minimize box or a simple tweak of the system menu.
One of the favoured solutions I've seen in a related Q&A was to make the window "NoResize", but I want most of them resizeable. Another answer was to customize the title bar... is that really necessary? Would it be possible/feasible/advisable to access and tweak the system menu in WPF? Any "gotchas" in doing so?
I have a serious Performance issue in my Silverlight project, when I run my project the CPU usage is going up 80% - 90%
the computer go down!!!, these are the major feature of the project:
1- We are using Silverlight 4.
3- We are using MVVM pattern, which means all data source, states are Binding with the properties in the View Model.
4- Most of the controls are created dynamicly in code.
5- We have a reference for the Main control in the Main view model which is the container of all generated control.
6- In our controls we have many of layouts (Grids).
7- We have Main view model which is the container of all children view models in the system.
8- We have lots of states and animations.
9- We don't use the Relay commands, we are using the regular commands and events, so we raise the event and handle it's parent (we have lots of events).
Is there any of the above causes the performance problem??? I thinks that there is a issue in the Silverlight itself, is there any Silvelight 4 update for performance.
I appreciate any help,
Thanks
A complex application is likely to have performance issues to resolve. The use of data-binding and various events, while great for structuring your application, can make it hard to see what's going on. The control flow may not be obvious, for example code may be executing multiple times due to cascading events/property changes.
I'd recommend using a profiler to see what is consuming most CPU time - JetBrains DotTrace is one I've used with Silverlight, see other questions for more. Then you can focus on the problem areas.
If your application is becoming progressively slower over time, it would be worth investigating whether there are memory leaks also.
Are you using DropShadowEffect anywhere? In which case, you might want to try removing them. I've had this issue once. A template included a DropShadowEffect which made the CPU max out, removing it solved the problem.
In my experience, your 9th point is usually the culprit.
Make sure that you release the event handlers in your classes when you're done with them. In almost all cases where I've seen performance degradation in Silveright or WPF is was the improper handling of event delegates.
As one of the comments pointed out, use a performance profiler and you'll most likely see that the event handlers are consuming an inordinate amount of RAM...meaning that they're sticking around after they're supposed to, and responding to events.
So the performance issue stems from having many objects or controls staying in memory and responding to events.
That's my best guess.
Hope it helps.
I find that the winform tool tips behave very erratically. They seem to randomly decide to do nothing, show up or disappear when I perform the same hovering/clicking/etc actions.
Is there some pattern that I'm missing? Do I just not understand the UI technique to bring up a tooltip? Is this a common problem? Do people actually expect tool tips to work this way?
Tooltips display automatically. That's a bit of a problem, the native Windows control has counter-measures in place to avoid displaying tips too often, potentially wearing out the user with info that has been shown frequently enough. Not exactly sure how that rate limiting is implemented, accumulated time is a factor (like 60 seconds), possibly also the number of times it was displayed.
The SDK docs do not document the implementation details. There is also no message available to forcibly reset the rate limiter. I do think that passing another control in the Show() method resets it.
All and all, it does mean that the ToolTip control is really only suitable to act as a traditional tool tip. It doesn't work well as a 'dynamic label'. which is your alternative, a Label control with BackColor = Info. Albeit it not quite the same because you cannot easily make it a top-level window.
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