Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    listgrid FormulaBuilder positioning

    Hi,

    I'm using Smartclient Version v9.1p_2014-03-03/Enterprise Development Only (2014-03-03) and Chrome version 33.0.1750.146 beta-m

    Is there any way to control the opening position of a listgrid's formulaBuilder window?

    Setting a listgrid's "canAddFormulaFields" attribute to true allows use of the formula builder window but I can't see any way to position this dialog.

    If it's not possible to position it, is there some kind of workaround? I have tried the following unsuccessfully:

    It is possible to to create a custom FormulaBuilder window (by using a modal window and adding an instance of the FormulaBuilder class to it). This gives me control of the window position but I can't find any comprehensive documentation on how to properly link this FormulaBuilder to the listgrid.

    #2
    No, there isn't currently a way to position the FormulaBuilder that is automatically created and managed by ListGrid.

    What are you trying to do with it? This is a strange point of customization that no one has ever asked about..

    Comment


      #3
      We have quite a complex web application that's built using a native browser (awesomium). What happens is that the web page is actually a virtual page (with large dimensions) that could be much larger than the screen. At runtime this page is sliced up to show the actual pages. So what's happening with windows like the formula builder is that it's opening in the middle of this virtual page which is actually off screen. This is why I need control of the x,y co-ordinates.

      With autoChild windows like the fieldPickerWindow I am able to position it by trapping certain events and then "moving" the window. However as far as I can tell this isn't possible with windows like the formulaBuilder.

      Comment


        #4
        For added clarity our application can be described as a native+web application that consists of a custom browser written in Qt that uses the Awesomium headless browser to render our SmartClient web page

        Comment


          #5
          Well, we can make this particular widget into an AutoChild so you have the same configuration hooks you're using elsewhere, however, does this really solve the general problem for you?

          There are built-in dialogs like isc.say(), isc.ask(), the LoginDialog, placement of translucent clickmasks, and lots of other cases to consider. We haven't audited things to make sure all of these would support custom positioning (again because no one would normally need it..).

          If you've pretty much solved the problem for all of these, then maybe the FormulaBuilder is the only gap. If not, a different approach might make more sense, such as a new API to specify the "effective" screen area that the entire system would respond to, including subtle cases like clickmasks.

          Comment


            #6
            We've exposed a new autoChild, DataBoundComponent.fieldEditorWindow - from builds dated March 13, you can just set autoCenter: false on grid.fieldEditorWindowProperties as you would with other autochildren

            Comment


              #7
              That's great thanks, that will definitely be helpful in the short term.

              Your point regarding the general problem is valid. Every time a Smartclient widget opens and manages child windows it's possible that these windows will appear off screen in our custom browser. With popups like isc.say() we simply use our own dialogs but obviously widgets like the FormulaBuilder we don't want to re-do from scratch if possible.

              I'm not sure on the best approach to deal with this but I'll put it to our team.

              Comment


                #8
                I've downloaded a new build (Version v9.1p_2014-03-16/Enterprise Development Only (2014-03-16)) and the new fieldEditor autochild window now works quite well. I'm able to position it dynamically by overiding the draw method.

                One thing that is quite strange is that the fieldEditor window (which is by default non-modal I think) is confusing to use unless it's made modal. Each time the window is invoked from the context menu, a new instance is created so you end up with multiple fieldEditor windows that don't behave as expected.

                Comment


                  #9
                  It is modal by default for that reason. You may have somehow inadvertently made it non-modal? Perhaps you override a method but did not call Super()?

                  Comment


                    #10
                    I don't think so but that's fine, I'll just set it to modal.

                    Comment

                    Working...
                    X