Having re-read for comprehension this time, I see that I was thinking of [SERVICES_EXEC] not [FILES]. My bad. 

Hey Colin, I'd probably solve your issue a slightly different way.... I'd store site specific configuration details in a table - and load the table at startup into a list. Included in this table I've had the mapping of a form name to another form name - thus I'd keep the 'normal' form name as the key, and the alternative form name as a 2nd column. getlistitems/id from the list at the time of activate - if found - activate the $valuepart and all's good... otherwise, just do the normal activate... Knut

Hi Knut, it's a really clever implementation hwat you describe: activate map_component("my_component").EXEC("123",12) So all you need is a global function map_component returns string with componentname_in returning $item(componentname_in,$$component_map) if not "" or componentname_in otherwise. If I have a chance, I will give it a try in a couple of scenarios and uniface versions

Colin said In classic deployment the .asn file can be used to redirect which component is activated i.e. in the [FILES] section just add a line that looks something like component1.frm anothercomponent.frm. Whenever the uniface proc code runs or activates component1, anothercomponent actually executes. Is there an equivalent in standardized deployment? If not, what would you recommend as a good way around it?

I do believe this is still do-able. The uniface code is unaffected by deployment, so the switch should occur as per the current method. I think the few times I tried it under classic deployment, I hit signature problems, but I don't know why. So for this situation we have done something between your solution and Knut's, in that we store a logical in the asn file, and use this to switch the activate.  if($logical("MY_COMPONENT") != "")      v_inst = $logical("MY_COMPONENT") else     v_inst = "MY_COMPONENT" endif newinstance v_inst, $my_comp_inst$

Colin said Hi, In classic deployment the .asn file can be used to redirect which component is activated i.e. in the [FILES] section just add a line that looks something like component1.frm anothercomponent.frm. Whenever the uniface proc code runs or activates component1, anothercomponent actually executes. Is there an equivalent in standardized deployment? If not, what would you recommend as a good way around it? Our company has an application that we sell to end users. Most of the time the standard version is exactly what they are after but there are always exceptions. When the user doesn't exactly like what we have (usually with special form layouts like invoices etc) we just write a version that suits them and then use the redirection in the FILES section to make sure the correct component is run. VERY easy. If something similar is not available in standardized deployment I will have a HUGE and potentially error producing maintenance problem trying to ensure the correct versions of components are run. Thanks, Colin Douglass  

Hi Colin, With standardized deployment you could create two different UAR files: one containing the standard version of component1 and one with the user-defined version. Let's say application.uar is for the standard components and customer123.uar includes the user defined components. In that case you would specify the UAR files as follows:

[RESOURCES] customer123.uar application.uar Now Uniface will first check customer123.uar and if it cannot find the requested component then it will look in application.uar. I realize that this setup requires two separate development environments: one for the standard application and one for the user-defined changes (meaning one repository for each end user that requires customized changes). Hope this helps. Kind regards, Daniel

Hello, I have a question about those edc and edx directories in the resource directory. They keep the information about entities (and fields...). Are these resources (edc and edx) required for deployment, I mean are they important during runtime? For example, if we change any entity, we change it in database, recompile and send the components, which uses the entity... must these files in edc and edx be updated as well? Kind regards, Zdeněk Socha

The videos from the deployment webinar are now available on YouTube:   https://www.youtube.com/playlist?list=PLec4UnOD-AIKJTaFJ4DJXunUEyc8NSGRb

sochaz said Hello, I have a question about those edc and edx directories in the resource directory. They keep the information about entities (and fields...). Are these resources (edc and edx) required for deployment, I mean are they important during runtime? For example, if we change any entity, we change it in database, recompile and send the components, which uses the entity... must these files in edc and edx be updated as well? Kind regards, Zdeněk Socha

Hello Zdeněk, AFAIK the edc (and edx) files are only needed when copying or converting data (e.g. using the idf command line switch /cpy or $ude copy). Hope this helps. Kind regards, Daniel Iseli Uniface Support

Hi, In classic deployment the .asn file can be used to redirect which component is activated i.e. in the [FILES] section just add a line that looks something like component1.frm anothercomponent.frm. Whenever the uniface proc code runs or activates component1, anothercomponent actually executes. Is there an equivalent in standardized deployment? If not, what would you recommend as a good way around it? Our company has an application that we sell to end users. Most of the time the standard version is exactly what they are after but there are always exceptions. When the user doesn't exactly like what we have (usually with special form layouts like invoices etc) we just write a version that suits them and then use the redirection in the FILES section to make sure the correct component is run. VERY easy. If something similar is not available in standardized deployment I will have a HUGE and potentially error producing maintenance problem trying to ensure the correct versions of components are run. Thanks, Colin Douglass