Let's have some positive approach how to add some operations to all the components. Trust the Beatles: "It's EASY! All you need is ..." - We need the metadictionary so we have to add to the IDF start: "/ins META" - We add a library MYENRICHLIB with an Included Proc NEWOPERSET - Finally we need a simple new dialog form ENRICHOPER. As the operations are stored on form level, we paint the UFORM on the paint tableau as a multi-occurence entity Metadictionary is out-of-the-box read-only, so in our form, we have to enrich the local WRITE trigger with a simple "write" Lets use "Load Fields" to have at least ULABEL visible and SFUNC to see the contents of the OPERATION trigger. Now comes the important code (I abused the menu trigger for it): forentity "UFORM" SFUNC = $concat(SFUNC,"%%^#include myenrichlib:newoperset") endfor - To ACT AS A PROFESSIONAL, it's time to export all the forms before modification. - Now we use our ENRICHOPER in testmode with a couple of GOLD commands: GOLD-R to retrieve all the forms GOLD-C to invoke the MENU trigger (check the result) GOLD-S so all the record are stored That's it. Depending on the amount of forms, processing may take a little while. Have a nice Chritmas and a Happy New Year, Uli

adkinsl said This was also my recollection of the conversation discussing access to the DICT in the future -- that the API would be the preferred method, but access would still be open to developers as it always had been. Unfortunately, that discussion happened at the last conference which was prior to my first Uniface 10 migration (hoping not to be my last). I've had several conversations with Uniface folks since then and while I still hate that I don't have access to the DICT currently in 10.2, I'm willing to wait on the promise that it will be restored in 10.3....along with other important functions already discussed at length with a "passenger". I'm hoping to possibly see these positive changes in New Orleans in February.....or at least hear about them if those last 1.5 sprints end up in a light job instead   

Don't think there was ever going to be any point in documenting DICT or providing UMETA to import with Uniface 10.2. We always knew, and were public with the fact that it was not the final thing, and was definitely going to change. 

This was also my recollection of the conversation discussing access to the DICT in the future -- that the API would be the preferred method, but access would still be open to developers as it always had been. Unfortunately, that discussion happened at the last conference which was prior to my first Uniface 10 migration (hoping not to be my last). I've had several conversations with Uniface folks since then and while I still hate that I don't have access to the DICT currently in 10.2, I'm willing to wait on the promise that it will be restored in 10.3....along with other important functions already discussed at length with a "passenger". I'm hoping to possibly see these positive changes in New Orleans in February.....or at least hear about them if those last 1.5 sprints end up in a light job instead

Knut said Adrian, Of course there's a lot of water under the bridge since the last NAUUG - however the sentiment back then was for the lab to build a number of api functions on top of the repository and not give us access to DICT directly. If this has changed, I'll sit corrected and rejoice. Knut  

I don't think I said that Knut, I said that our preferred way was to provide APIs because they would be future proof against any future repository changes.  But it has always been our intention that we would document the Uniface 10 dictionary when complete (with Uniface 10.3). Even if we did not, we can't stop access to those tables.  So to put an end to any more fake news..  Unless something changes in the next couple of weeks. (1 1/2 sprints) The 10.3 release will have the finalised Uniface 10 repository, and will include the umeta file to import into the IDE. 

Adrian, Of course there's a lot of water under the bridge since the last NAUUG - however the sentiment back then was for the lab to build a number of api functions on top of the repository and not give us access to DICT directly. If this has changed, I'll sit corrected and rejoice. Knut

Knut said Of course not - since they're seriously contemplating not to publish the data dictionary I'd say the lab is indeed saying "thou shall not". Knut  

are they? 

Gilles, Of course not - since they're seriously contemplating not to publish the data dictionary I'd say the lab is indeed saying "thou shall not". Then again, I also believe in the 11th Commandment - "Thou shall not be found out.".... Knut

Knut, Uniface does not want us to modify xml export file too ?  add include proc in  <DAT name="SFUNC" xml:space='preserve'> element and reimport. Gilles.

Uli - afaik - the powers in Amsterdam in their wisdom will decide how we're supposed to work (or not) - after all, Uniface is made by developers for developers.... I guess it really boils down to staying with Uniface 9.x until (if ever) we get the same level of flexibility in Uniface 10....

Knut: So what solution has the Lab to offer in this case?

Uli, This is exactly the sort of solution the lab doesn't want us to do - ie. play with / use the META to do global updates - so stop it!.... Knut

Session Panels execute operations on the active form. In case you use Form Templates in your forms, just add the needed operations in the template(s) and compile everything. The operation is available, even if an external variation does not contain the needed operation. Wolfgang

Hi, Do you try macro "^switch_key" , if you don't already use it in form , can activate <switch keyboard> trigger of the startup shell .... Gilles. Merry CHirstmas.

Exactly. But he wants al solution at session level . So i think that the panel i a session panel and not a form panel. He should need to change that part   merry christmas

The O.P.'s original point was that they didn't want to have to put a specific operation on every form so that the session panel would always be able to find the operation to call it.  You cannot define an operation on the application start up shell, so the operation must be compiled into every form.  We are looking for something you can access via the start up shell, so the code only needs to be compiled in once, but panels can't call anything but operations, and start up shells can't have operations defined. Catch 22.  If the user can define an operation against every form (using templates, or hacking the registry or similar), then the postmessage is (largely) redundant, as the operation can include the code necessary anyway.  It would appear to me that panels are largely ignored by Uniface development as being 'old school' or something. All their examples use buttons painted on the forms themselves, and the panel functions seem well behind the times.  Trouble is, if you want a U.I. with a nice consistent interface, they are so useful...... (where they are actually useful...  )

Iain Sharp said The panel cannot postmessage, only call operations. I thought of that, but rejected it for those reasons.   

Hi Iain, but it can call an operation which in turn starts a postmessage ? Just a 2-step way with some supporting API in a "hidden form" may solve the problem. Nice christmas and a Happy New year to all in unifaceland, Uli

The panel cannot postmessage, only call operations. I thought of that, but rejected it for those reasons. 

Did you try postmessage>asynchronous interrupt trigger?   Sergio

I appreciate the effort Knut, no luck though as you have found out yourself. Thanks again.

Well, well, well.... I'd always thought the panels would issue the equivalent 'macro' statement - it would appear the kernel does not issue the 'macro' statement - thus bypassing the keyboard translation table... Ah well, back to the drawing board. Knut

Have you tried to use the 'user key' trigger at appl startup shell level? in your custom session level panel - a macro "something" - mapped via keyboard device table - will be passed up to the 'user key' trigger.... Of course, there's no macro 'button' - but reassigning something like the 'ruler' or any other button which isn't used... maybe worth a try? Knut

Thanks for the reply Wolfgang, this was what I feared. Oh well, menus it is.   Thanks.