After moving a small set of smart objects into a frame in an application window I now get the error "User-defined function 'getDataModified' invoked dynamically but could not be found. (5639)" when the window initializes.
I haven't noticed any other issues with the application and there are no more error messages after it has initialized. I have another frame in the application window that doesn't produce this error and have gone through similar processes with similar windows without issue. I am not sure why this particular frame is giving me problems. I have recreated the frame and still have the same issue. A look at the ProSpy log seems to show the source to be the getDataModified function run from adm2/dataext.p. The other frame in the application is not a target for the getDataModified function but the one giving me problems is. I have added no procedures or functions to the frame and the just the usual smartLinks within the frame:
THIS-PROCEDURE , 'Data':U , h_bboard
h_dyntoolbar, 'Tableio':U , h_vboarda
THIS-PROCEDURE , 'Data':U , h_vboarda
h_vboarda , 'Update':U , THIS-PROCEDURE
h_dyntoolbar, 'Navigation':U , THIS-PROCEDURE
and within the window:
h_dboard , 'Data':U , h_fboard
h_fboard , 'Update':U , h_dboard
h_fboard , 'Navigation':U , h_dboard.
Does anyone have any idea what the problem might be and how I should address it?
thanks,
Paul
Progress 9.1E
Windows XP
After looking a bit deeper I found that the application window that doesn't raise the error has its appServer aware toggle checked while the one that does raise the error doesn't. Checking that toggle solved the problem but I don't know why. Should this be necessary? We are using a client/server setup. When should the appServer toggle be checked for a smartWindow?
thanks,
Paul
Note that this question should really have been asked in the Adm2 and Dynamics forum.
-----------
The issue you run into happens when an object (toolbar) tries to request state from another object (SDO) whose pass-thru link has not yet been realized. The SDO's getDataModified checks the UpdateSource's getDataModified, but the UpdateSource is still the SmartFrame, which does not have the function.
In the current adm2 the SDO getDataModified (in adm2/dataquery.p) only calls the UpdateSource if it is an instanceOf("DataVisual") to avoid this problem. If you wanted to fix this in 9.1E you would probably override getDataModified and add some similar check. InstanceOf does not exists in 9.1E though, so you would probably need to use ObjectType. It would be a bit difficult to come up with a generic check, since Viewers are Containers and the object could also be a browser.
After looking a bit deeper I found that the application window that doesn't raise the error has its appServer aware toggle checked while the one that does raise the error doesn't. Checking that toggle solved the problem but I don't know why.
This causes the SDOs to be initialized before visual objects and eliminates the problem.
Should this be necessary? We are using a client/server setup. When should the appServer toggle be checked for a smartWindow?
The AppServer aware toggle should be checked for any container that contains SDOs. Not only on SmartWindows, but child containers like SmartFrames and SmartDataViewers. (This is default for any new container built from shipped templates.) It ensures that all SDOs on all containers are retrieved with one request on stateless AppServers. If you do not set this there will be one request for each SDO. If you only have one SDO in the outer container then you probably won't get any performance benefit from this, but there's no reason to not always set this flag in standard adm2 or Dynamics. (I'm not sure how this flag works with state-reset or statefull Appservers, but I think it is just ignored).
Note: Existing applications might have customizations that prevent the use of AppServer aware containers. An AppServer aware container retrieves the data after all SDOs have been initialized, so SDOs that have an initializeObject override that expects data to be present on the client after the call to super will fail.
Message was edited by: Havard Danielsen
Added note
Thank you very much Havard. That is an excellent summary.
About the templates, in my experience, the default setting for new containers built from the AppBuilder templates is AppServer aware off. In the version I'm using it seems only SDOs and SBOs have AppServer aware checked by default. I don't recall checking that toggle on window that had it checked. I suppose I must have though as a quick review suggests there are very few, if any, other windows in my application that have that toggle checked. I will go through and check them all.
thanks again,
Paul
Thank you very much Havard. That is an excellent summary.
Because you included all relevant information.
About the templates, in my experience, the default setting for new containers built from the AppBuilder templates is AppServer aware off. In the version I'm using it seems only SDOs and SBOs have AppServer aware checked by default. I don't recall checking that toggle on window that had it checked. I suppose I must have though as a quick review suggests there are very few, if any, other windows in my application that have that toggle checked. I will go through and check them all.
Sorry, I forgot to mention that this was not the case in 9.1E. We added the AppServer aware behavior to containers in 9.1D, but the template defaults were not changed untill several releases later.