Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

    Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2994 in 3.1 beta.
  1. #1
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    71
    Vote Rating
    0
    Aleksandar Krstik is on a distinguished road

      0  

    Default GXT 3 context menus and dropdown lists apear behind GXT2 Windows (z-index)

    GXT 3 context menus and dropdown lists apear behind GXT2 Windows (z-index)


    I'm using the GXT 2 desktop app with GXT 2 windows with GXT 3 widgets inside. I have a strange problem when context menus, dropdown lists and other "popup items" are in question. Namely, what happens is that the popup item itself appears behind the GXT 2 window so I can't see it.

    I tried setting the initial z-index of the GXT 2 window to something lower and then the popup items show normally. However, whenever I open another GXT 2 window on the desktop, and then switch back to the previous one the z-index changes and the window again appears in front of the popping items.

    Specifically I have this problem with a grid context menu, and a date selector within a menu button, and also a comboBox within a menu button.

    My current workaround is to manually reset the z-index when opening popup items like so:

    Code:
    predefinedMenu.addShowHandler(new ShowHandler() {
                @Override
                public void onShow(ShowEvent event) {
                    predefinedMenu.getElement().setZIndex(99999);
                }
            });
    However, this really isn't an elegant solution for me and it adds extra work on complex layouts.

    Any suggestions on how to fix this behavior? Thanks!

  2. #2
    Software Architect
    Join Date
    Sep 2007
    Posts
    13,971
    Vote Rating
    132
    sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light

      0  

    Default


    The problem is that both GXT environments have their own zIndex management (XDOM.getTopZIndex()).

    There is no real solution for this.

    The only real solution would be to change the code from GXT 2 and GXT 3 so the XDOM.getTopZIndex() method works against the same storage.

  3. #3
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    71
    Vote Rating
    0
    Aleksandar Krstik is on a distinguished road

      0  

    Default


    I'm sorry to bump this post but as the above mentioned workaround is what's getting me through this thing, I wanted to ask for help on how to implement that 'fix' for a GXT3 ComboBox since it doesn't allow me to directly set the z-index of the dropdown menu like a context menu does.

    Any particular DOM element I could manipulate, or CSS style or something?

    Thanks a lot!

    EDIT: I was thinking something along these lines (this doesn't work):
    Code:
            comboBox.addShowContextMenuHandler(new ShowContextMenuHandler() {
                @Override
                public void onShowContextMenu(ShowContextMenuEvent event) {
                    Menu menu = event.getMenu();
                    menu.getElement().setZIndex(99999);
                }
            });

  4. #4
    Sencha User
    Join Date
    Jun 2011
    Posts
    5
    Vote Rating
    0
    lindsay.thurmond is on a distinguished road

      0  

    Default Workaround

    Workaround


    This is what I've been using for a workaround any time I need to show a GXT3 field over top of a GXT2 one. The result is that the GXT3 index ends up higher than whatever the current GXT2 one is.

    Code:
    public static void gxtZindexHack() {
        com.sencha.gxt.core.client.dom.XDOM.getTopZIndex(com.extjs.gxt.ui.client.core.XDOM.getTopZIndex());
    }

  5. #5
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    71
    Vote Rating
    0
    Aleksandar Krstik is on a distinguished road

      0  

    Default


    Thanks for sharing your workaround! However, even though it's MUCH more elegant than my "setZIndex(99999)" it basically does the same thing.

    My biggest problem with this is that sometimes you need to apply the z-index fix to some popup menu, dropdown list, etc. And more often than not it is very difficult to get to the actual DOM element that needs its z-index set higher. Sometimes I apply the fix to a menu with no success, only to later find out that I actually needed to apply it to the menu's child's child or whatever. If you know what I mean.

    Sometimes, I'm not quite sure which handler/listener to employ to be able to apply the fix on some particular element. A thing that comes to mind is the popup on hover of a grid's cell. I've yet to figure out a way in which I can display that popup from a gxt 3 grid on top of a gxt 2 window that contains the grid itself.

    Please do share if you've encountered and solved that particular problem.

    Thanks!

  6. #6
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,717
    Vote Rating
    87
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    We're working on a change in GXT 3 that will allow you to replace the z-index code with your own wiring - this will enable you you read directly from GXT 2's z-index to configure GXT 3.

    The basic issue here is that there are two sets of popups, and they have no way of knowing about each other - we can't build GXT 2 retroactively to know about GXT 3, and we do not want GXT 3 to depend on GXT 2 classes. Solutions like the one described are one option, but here is another:

    Ensure you are only using one set of popups, either GXT 2 or 3. This may mean continuing to use GXT 2 Window classes as you begin your development, or better yet, as the very first step of changing to GXT 3, just go and change all of the Window instances and other popups. This will at least start you down the migration path, and will ensure that popups are layered in a consistent way. You can then tell what remains in GXT 2 code to display above all other popups - combo boxes, tooltips, etc can be pushed up to some astronomically high z-index.

  7. #7
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,717
    Vote Rating
    87
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    With 3.1 beta released now, I'm posting again to share a way that should work to make GXT 3 use the GXT 2 z-index wiring:

    First, create a XDOMImpl subclass, somewhere in your project:

    Code:
    public class Gxt2ZIndexXDOM extends com.sencha.gxt.core.client.dom.XDOM.XDOMImpl {
         public int getTopZIndex(int i) {
             return com.extjs.gxt.ui.client.core.XDOM.getTopZIndex(i);
         }
    }
    You can also override other methods in this if you need other customized wiring for whatever reason.

    Then, in your .gwt.xml, wire this up as the default implementation for GXT to use, somewhere after your inherits statements:

    Code:
    <replace-with class="path.to.my.Gxt2ZIndexXDOM">
         <when-type-is class="com.sencha.gxt.core.client.dom.XDOM.XDOMImpl" />
    </replace-with>