Hi lalit, perhaps the blog and the replies are interesting for you: http://unifaceinfo.com/why-you-should-clean-up-dead-code/ One option is the use of the proc tracing with a followed analysis of the very long files created this way. But this is in fact the only way which does not require changing the code in the components and recompile them. I'm puzzled when you say, "compiling all forms is difficult at present": do you not have the sources handy to just run a "IDF.exe /all" ?

Hi lalit, if you follow Theo's suggestion, there are some common pitfalls when dealing with the metadictionary: do not forget to put a "write" in the WRITE-trigger of UFORM (the metadictionary is delivered with empty write and delete triggers because it's easy to mess up the complete repository) and be sure that you commit the database changes after your store.

Wrong abstraction level Lalit. You are changing the definition of the UFORM table. You chould be changing the content of the rows of the UFORM table. MAKE VERY SURE THAT YOU HAVE A BACKUP !!! You are not an experience Uniface developer and making changes directly of the DICT tabls is DANGEROUS !!! So go back to the original definition of the DICT model. Now go to the Form editor and create a new Form. Let's call it ADDLOG. On that Form paint the entity UFORM of the DICT model. Paint the fields that you need, say ULABEL, UTRANSACT and SFUNC. UTRANSACT has the component type (Form, Service, Report ect) Compile and retrieve. Now you see the data that you may want to change. It is up to you to add code to this simple Form ADDLOG that will automatically add some code to the start of the SFUNC field. MAKE VERY SURE THAT YOU HAVE A BACKUP !!! You are not an experience Uniface developer and making changes directly of the DICT tabls is DANGEROUS !!! Theo

Hi lalit, looks like you completely misunderstood the concept how uniface works. It's not the model, but the data in the repository (the value of the field SFUNC) which needs to be amended. That's what you do if you open the component for editing and add your operation init into the operations trigger of the component. It makes no sense at all to put this code in any trigger of the field in the data model. the "operations" keyword is restricted to only a couple of triggers, all the other should create error messages. As long as you do not paint the entity (and the field) on a form, the code will not be inherited.

Step 1 : Open MODEL DICT ->Go to Entity UFORM -> Go to SFUNC -> go to field SFUNC Step 2 : Added below code in all SFUNC field triggers (Value changed,Validate field,start modifiction..etc) operation init putmess "hello 1" end Step 4 : Analyze model Step 4 : Opened a sample form abc.frm ,compiled it What I undesrstand is code from SFUNC triggers should be present in operation trigger of abc.frm after compilation. Or what I am expecting is not the way it will work?

Hi lalit, looks like your implementation to append to the SFUNC field was not correct. As a standard, the metadictionary is delivered with an empty write trigger; so nothing is written to the database. Sometimes, there is a store with a commit missing or not executed which cause a rollback when you close your application. I do not know what you mean with: (code in all triggers) was not added automatically in sample form after compilation. can you give me some more hints what you have done to expect some "automatically added code after compilation"?

Setting $ioprint to 512 will put a line in the log files for each activate (and no more), then you'd need to clear out the log files by parsing them for information on the way out of the application and then deleting them. Use %p to get a log file for each session. Changing things using the DICT model etc will require a recompile of all the forms in the system, but gives you much more control over what you want to log and when.

Actully logs cannot be activated as these are production server , we have space limitation as activating logs will create heavy log files. I have acess to DICT model etc , if there is something i can modify and apply the changes there ..it will solve the issue.

$ioprint=512 causes all activates to be logged in the uniface log files, You'd then need some form of cleanup on leaving the application which read the log file and filled the data file with this. But getting the actual time out of the log file is problematic.

Thanks Uli Difficult to compile means I cannot compile all of them and get it released in production , as this is running project. sorry for confusion. Hence I was looking for something where i can just modify some global stuff and then get it logged in some table.

AND MAKE VERY SURE THAT YOU HAVE A BACKUP !!!

Thanks a lot for the option option 1 : what i understand is i need compile all forms again to have that , which is slightly difficult at present. option2: Can you explain this in detail, this one looks like feasible option for our prj , if possible with simple example.

Do you currently use the init operation in the operations trigger of the components? If not, you can add an init operation to the operations trigger, which uses $instancename, $componentname, and $componentname($instanceparent) (and possibly even the call stack) to log the information. You should be able to 1. Add the init operation to any component templates which will automatically compile it into all components still bound to the template. 2. Add the init operation using a simple span through UFORM (using the DICT model)

-yes screens are called using activate . -code added in MODEL->DICT->UFORM->SFUNC field->(code in all triggers) was not added automatically in sample form after compilation.

The URR makes sense only after the compiles have been done, not before. do you call your forms via activate? The INIT operation will not be avctivated if you use RUN to start your forms, as the documentation reads: Init Defines the component behavior when a component instance is created with newinstance (or by activate when newinstance is executed implicitly). Have you checked in your sample form that the modification of the repository really ended up in the operations trigger? Perhaps you can test in the IDF at first, if the sample form works when you use the IDF test mode. Next would be to run your production application with the /deb switch to see if and how the component is called.

Hi Uli,sochaz Thanks for testing i tried below things 1)MODEL->DICT->UFORM->SFUNC field->coded below things in all triggers. 2)regerated URR and compiled one sample form. 3)Released both and checked. The code was not called , is there something else that needs to be done or i need to add manually code in the form? coded below things ---------------------------------------------- operation init putmess "hello 1" end

Hello, we have recently implemented quite the same thing as Uli mentioned. We put some kind of #include COMP_LOG into all init and cleanup operation of every single component. In this include, there is a simple code to activate a servis passing him some information (componentname, operation etc ) which does the rest... it logs all inits and cleanups of all components of our application into a sipmle table. We log something like componentname, number of inits, datetime of last init, number of cleanups, datetime of last cleanup... Please be aware that logging in database might be a bit tricky on transaction. We use Oracle, so we use sql and autonomous transaction, so this logging does not influence other data. Zdenek

Hi lalit, as the description of the field says, the INIT datafield holds the code for the EXECUTE trigger, so you better not touch it. what you need is an OPERATION INIT which has to be placed in the field SFUNC of UFORM. But be careful because there may be other operations already defined in this trigger which must not be overwritten. For flexibility reasons i recommend you just place the operation definition and a #include into the code of each form. operation init #include OVERALL:INIT_CODE end ; operation INIT then you create a library OVERALL and an included proc called INIT_CODE. If you want to change/enhance the functionality, there is just a change in this include proc necessary (and a recompile of all the forms)

Hmm ok , will see the first option also. For DICT model modification I have acess to MODELl->DICT->UFORM->INIT. Do i need to add code in Trigger of field INIT? I tried but it didnt work