Anyway to use Session Panels to trigger startupshell triggers?

Author: bartonm@westinghouse.com (radarhead)

As the title asks, is it possible to use a custom function in a panel, at session level to trigger triggers in the startup shell? As far as I can tell Panels only let you trigger custom operations, Unfortunately the startup shell does not cater for operations.  I need it to trigger something (an include proc) at session level as I really don't want to have to add the operation trigger to the hundreds of forms we have in our application. I could use a menu but the visual impact of menus is just lacking compared to panels. Thanks in advance.

22 Comments

  1. 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


    Author: gypsilon (wva@gypsilon.de)
  2. Thanks for the reply Wolfgang, this was what I feared. Oh well, menus it is.   Thanks.


    Author: radarhead (bartonm@westinghouse.com)
  3. 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


    Author: Knut (knut.dybendahl@gmail.com)
  4. 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


    Author: Knut (knut.dybendahl@gmail.com)
  5. I appreciate the effort Knut, no luck though as you have found out yourself. Thanks again.


    Author: radarhead (bartonm@westinghouse.com)
  6. Did you try postmessage>asynchronous interrupt trigger?   Sergio


    Author: fearandir (fearandir@gmail.com)
  7. The panel cannot postmessage, only call operations. I thought of that, but rejected it for those reasons. 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  8. 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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  9. 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... Cool )


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  10. 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


    Author: fearandir (fearandir@gmail.com)
  11. 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.


    Author: Gilles (gls.tools@free.fr)
  12. 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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  13. 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!.... Cool Knut


    Author: Knut (knut.dybendahl@gmail.com)
  14. Knut: So what solution has the Lab to offer in this case?


    Author: ulrich-merkel (ulrichmerkel@web.de)
  15. 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.... WinkWink


    Author: Knut (knut.dybendahl@gmail.com)
  16. 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.Cool Gilles.


    Author: Gilles (gls.tools@free.fr)
  17. 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.".... LaughLaugh Knut


    Author: Knut (knut.dybendahl@gmail.com)
  18. 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? 


    Author: Adrian Gosbell (adrian.gosbell@synapse-i.jp)
  19. 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


    Author: Knut (knut.dybendahl@gmail.com)
  20. 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. 


    Author: Adrian Gosbell (adrian.gosbell@synapse-i.jp)
  21. 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 Laugh


    Author: adkinsl (adkins.larry@gmail.com)
  22. 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 Laugh  

    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. 


    Author: Adrian Gosbell (adrian.gosbell@synapse-i.jp)