Announcement

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

    Help with CanvasItem

    The Dynamic form that contains this canvas item is added to a values manager. I keep getting the following error when attempting to open the view that would expose this form.

    15:19:04.028:MUP1:WARN:CanvasItem:isc_CanvasItem_0 :Observer: [CanvasItem ID:isc_CanvasItem_0 name:schedTakeoffTime] is already observing method '$lf' on object '[DynamicForm ID:isc_DynamicForm_1]', ignoring
    15:19:04.028:MUP1:WARN:CanvasItem:isc_CanvasItem_0 :Observer: [CanvasItem ID:isc_CanvasItem_0 name:schedTakeoffTime] is already observing method 'setFocusItem' on object '[DynamicForm ID:isc_DynamicForm_1]', ignoring

    The form fails to render. I tried posting this under a related thread several days ago and still have had no response. I would appreciate a timely response as we have paid for support.
    Last edited by jpappalardo; 24 Sep 2014, 09:24.

    #2
    In that other thread you appeared to be asking a user for help with code he had posted, not with SmartGWT as such.

    If you think there's a SmartGWT problem and it involves ValuesManager, can you post how your using ValuesManager with this code?

    As far as failure to render, if you are seeing only warnings and not a JS error, then be sure you have drawn the component, and check the Watch Tab in the Developer Console to see if it is not actually drawn.

    Comment


      #3
      Here is the utilization of the SplitDateTimeItem


      Here is a piece of code that implements using the form containing the item

      valuesManager.addMember(sortieForm) is line 78 of MissionPlanForm from the following errors
      Last edited by jpappalardo; 24 Sep 2014, 09:24.

      Comment


        #4
        It looks like there's a different issue here that's actually causing the failure to render, and a null pointer exception. This line:
        Code:
         return form.getValueAsString("timeOnly") != null || !form.getValueAsString("timeOnly").isEmpty();
        is attempting to call "isEmpty()" on null if passed null. If replaced (in both places where it occurs) with this:
        Code:
                                    if (form.getValueAsString("timeOnly") == null) return false;
                                    return !form.getValueAsString("timeOnly").isEmpty();
        This appears to get things working.

        The warning about already observing methods looks to be harmless but we're checking the framework and will likely be getting rid of the warning.

        Also note that 'setID(...)' as part of a standard constructor is probably not a good idea. The ID must be unique on a page, so if you create more than one instance of a class you're likely to end up with colliding IDs (which will cause the pre-existant instance to be destroy()'d)

        Let us know if this doesn't get things working for you

        Thanks
        Isomorphic Software

        Comment


          #5
          That got me closer. I cannot seem to find a way to storeValue without getting a null pointer exception. Here is the revised class.



          I have tried stepping through the debugger to understand where the NPE is coming from. When I watch the the storeValue calls, formItem is not null and is a SplitDateTimeItem, and date = is the Date that I entered in the form. However, somewhere up higher in your logic I end up with an NPE. Here is the error
          Last edited by jpappalardo; 24 Sep 2014, 09:24.

          Comment


            #6
            Is there no hope for this implementation? Am I better off just having seperate fields in the entity?

            Comment


              #7
              One of our developers is taking a look -- we'll post a response shortly.

              Comment


                #8
                The issue appears to be that the call to "storeValue()" is being passed a [java] date object and this is not being automatically converted.
                We'll make a change to the framework to ensure this gets handled in the future, but for now you can explicitly perform the conversion in your own code - like this:

                Code:
                                                JavaScriptObject jsDate = JSOHelper.convertToJavaScriptDate(date);
                                                ((SplitDateTimeItem)formItem).storeValue(jsDate);
                Please let us know if that doesn't resolve it

                ==
                Update: We have just made a change to the storeValue method in the SmartGWT codebase to handle dates properly so this workaround will no longer be necessary in nightly builds dated March 14 or greater cut from the 3.0p or 3.1d branches
                Last edited by Isomorphic; 13 Mar 2012, 10:33.

                Comment


                  #9
                  I hate to revisit this thread but I am having issues with this IE. It works fine in FF.

                  SmartClient Version: v8.2p_2012-04-26/PowerEdition Deployment (built 2012-04-26)

                  SplitDateTimeEditor

                  ListGrid using the editor


                  Actions to produce an exception:
                  1. Begin editing a new record
                  2. Enter a date via picker
                  3. Enter a time
                  4. Click on the next field to edit it(its a selectItem)

                  Dev Console output

                  Some issues I am having in FF with this component.
                  1. DatePicker requires a double click to open up the calendar.
                  2. I can't click my way out of editing a record in the grid, I can manage way out of editing via the tab button(sometimes)
                  Last edited by jpappalardo; 24 Sep 2014, 09:25.

                  Comment


                    #10
                    We've made some changes to the way this behaves - will show up in the next nightly build. Please give it a try and let us know if you continue to have problems

                    Thanks
                    Isomorphic Software

                    Comment


                      #11
                      The only difference I observe is now in firefox, after entering a value in my canvas item, and trying to enter a value in the next field, the canvas item expands horizontally. I still cant click out of edit mode in IE or FF.

                      ***EDIT***
                      I was still seeing the exception in IE until I cleared IE's cache
                      Last edited by jpappalardo; 10 May 2012, 13:25.

                      Comment


                        #12
                        Can you clarify? It sounds like IE's major bug (exception) is fixed but there are still outstanding issues with being unable to dismiss the edit in both IE and FF?

                        How exactly do you reproduce the remaining issue(s)?

                        Thanks

                        Comment


                          #13
                          When either adding a new record, or editing an existing record in the list grid as posted earlier. The only way out of editing mode is via the Tab button. This would not be so horrible except that tabbing does not work as expected. Instead of Tab just leading you thru the editable record, it takes you thru the ui and the browser items and then will eventually let you out of editing.

                          The exception in IE is resolved. In most list grids you can just click outside of the editing record and the edit mode is escaped. Perhaps I need to add something to my canvas item to handle tabbing, or I'm missing a setting in the list grid for tabbing out of editing mode?

                          Comment


                            #14
                            To elaborate on what I am observing in FF I have put together some pics of the list grid before edit, after starting an edit, after input into the canvas item, and after trying to move to editing the next field.

                            Note that edit mode always starts editing the second column rather than the canvas item.

                            ***EDIT***
                            This behavior did not occur before the 05-10 nightly
                            Attached Files
                            Last edited by jpappalardo; 10 May 2012, 16:38.

                            Comment


                              #15
                              We see the problem whereby editing defaults to the second field (not the first field which has the custom canvasItem based editor) and have made a change to address this (Will show up in the next nightly build).

                              Other than that, the test code you've passed us earlier in this thread doesn't seem to reflect the problems you describe and your attached screenshot.

                              In our testing clicking outside the edit item always dismisses the edit as expected.
                              Can you verify whether clicking outside works for you with the test case attached to this thread. If it does, could you show us a reproducible case where it fails for you.
                              If it does not, can you let us know exactly what build version you're seeing fail, what browser (full version) / and OS combination you're seeing the problems with, whether you're running in compiled mode or hosted mode, and the exact step by step process to see the error occur.

                              As an aside - we are seeing some unexpected behavior around tab keypresses. These are a result of the ListGrid being unable to determine whether when a user presses tab focus should go to the next editable cell in the grid or be left alone.
                              We have an engineer tasked to investigate whether we can solve this in a general way so the framework takes care of this for you but for now the best way to proceed will probably be to apply explicit keypress handlers to your actual sub items.
                              - So a tab keypress on the first item will put focus onto the second item (and cancel the event to avoid any other focus change), and a Tab keypress on the second item would call "startEditing()" on the next cell of the listGrid, and again cancel the event.

                              Comment

                              Working...
                              X