1
0
-1

I have just migrated our V9 application to V10. I have done no manual modifications as yet to the code, and am relying on the migration path. 

In V9, I have a contained form (which enforces non-modal, attached), which is instantiated using newinstance and assigned to the valrep of a tab widget. Inside this form I use $instanceparent to refer to the instancename of the component with the tab widget on it. 

In V10, The "Is independant form" value is N and the window properties show as contained, non-modal, attached. However, at run time the value of $instanceparent is empty and trying to :-

activate $instanceparent.operation() 

returns -57 instance not known. 

This obviously throws a large spanner in inter component communication. 

Anyone know of a migration issue or similar which would cause this? 

Looking at the $detachedinstances, and their children shows that the parent program is 'correctly' attached to several components, but several others it SHOULD be attached to show as detached. 

The components are all started with a simple newinstance "COMPONENTNAME", Variable  where variable is empty and the instancenames are generated. There is no modifier to the newinstance. 


Help...

Iain

  1. Iain Sharp

    Given the new inheritance behaviours it might have some bearing that the program I'm looking at was originally created from an (old style) template, which was NOT a contained form, the Inherits settings are set to Inherits:T Inherits From:cpt::templatename:

    It is still set to non-modal attached however, and so is the template(modeled) component. 

  2. Iain Sharp

    Further info, since this is a test migration, I tried clearing the modeled component name. This appears to have stopped the behaviour, which means it is something inherited from the modeled component which is causing it to instantiate as a detached instance. 

    The modeled component is also defined with window properties of non-modal, attached it's just not set up as contained. So I can't see what would lead to this behaviour even through inheritance. 

  3. Iain Sharp

    And re-attaching it to the modeled component re-instates it being instantiated as a detached instance..... 


CommentAdd your comment...

3 answers

  1.  
    1
    0
    -1

    I've escalated this to a logged support call, I'll let you know what conclusions we reach. 

      CommentAdd your comment...
    1.  
      1
      0
      -1

      Hi,
      We have also just migrated a quite large client/server application with about 600 forms and run into the same problem. In some cases activating forms from a tab widget commandbutton, the default attachment of the activated component is not working. I solved the problem by adding the /attached switch hardcoding to the newinstance command and this made it work fine. I have not had time to analyse this further, so I have not made any problem report about it to the helpdesk.

      Kind regards,
      Sten-Erik Sandas

      1. Iain Sharp

        Could you check whether the forms you had problems with were bound to a modelled component? This appears to be the differentiator in my migration, it’d be nice if the same was true of yours to localise the problem. 

      2. Sten-Erik Sandås

        Hi Iain,
        I have now made a larger investigation and could not find any commandbutton using newinstance not requirering a "/attached" before activating a non-modal component based on a component template.  So You might be right. 

        Investigation results:

        • about 600 components, about 90 % of them are based on component templates. 
        • about 1400 newinstances followed by mostly non-modal activates.
        • most of these are done before entering edit-mode of the component - no problem
        • about 170 commandbuttons using newinstance and activate
        • most of these commandbuttons are activating components not based on a template - no problem
        • Some are activating modal components based on templates - no problem
        • So far we have changed 25 newinstances in commandbuttons adding "/attached",
          they seems to all be non-modal component based on templates. Some of these corrected commandbuttons from on a normal form, some on tab-widgets - no difference

        We have also find some problems with migrating entities with locking strategy no-update. 
        Anyhow, for the rest, the migration seems to work fine.  Still some customer testing to be done, but it looks like we can go into production with uniface 10.3 a lot easier than expected.

      CommentAdd your comment...
    2.  
      1
      0
      -1

      We're in the middle of the process of migrating our application from V9 to V10. So far we haven't seen any problems with tab and contained forms.


      Now I have just quickly tested 3 most critical forms with tabs and in the debugger I can see that $instanceparent is correctly set to the parent. Otherwise it would be a big problem of course.


      As for newinstance we do not have the same scenario everywhere. I mean, sometimes we use newinstance/attached to make sure it is attached. But sometimes we just do newinstance with no switch. But in 99% cases we have special forms to be used as tab pages (contained) and they are designed to this. So in their definition the "Window Type" property is set to "Contained", so it's automatically Non-Modal, Attached.

        CommentAdd your comment...