temp table as a parameter
- Thread starter Doug_b
- Start date
You need to have the temp table defined in the source and destination procedures so a .i is the best way for that.
In the destination procedure
In the calling procedure
In the destination procedure
Code:
DEFINE INPUT-OUTPUT PARAMETER TABLE FOR tt-Menu.In the calling procedure
Code:
INPUT-OUTPUT TABLE tt-MenuI need a little more clarification
Main Program:
DEFINE TEMP-TABLE tPrinter_info <---- are you saying I should say "DEFINE INPUT-OUTPUT PARAMETER TABLE FOR ...." here?
FIELD fieldname as CHAR
FIELD userDescription as CHAR
FIELD deviceAddress as CHAR.
RUN Get_Printer_List (OUTPUT tPrinter_Info)
-- - - - - - - - - - - - - - - - --
PROCEDURE Get_Printer_List
DEFINE INPUT-OUTPUT PARAMETER TABLE FOR tPrinter_info.
Main Program:
DEFINE TEMP-TABLE tPrinter_info <---- are you saying I should say "DEFINE INPUT-OUTPUT PARAMETER TABLE FOR ...." here?
FIELD fieldname as CHAR
FIELD userDescription as CHAR
FIELD deviceAddress as CHAR.
RUN Get_Printer_List (OUTPUT tPrinter_Info)
-- - - - - - - - - - - - - - - - --
PROCEDURE Get_Printer_List
DEFINE INPUT-OUTPUT PARAMETER TABLE FOR tPrinter_info.
No, sorry was a little vague - what you need to do is to define your temp table in an include that you include in the top of both programs. That way you can be sure the definition is the same in both.
then...
RUN Get_Printer_List (INPUT-OUTPUT TABLE tPrinter_Info).
PROCEDURE Get_Printer_List
DEFINE INPUT-OUTPUT PARAMETER TABLE FOR tPrinter_info.
then...
RUN Get_Printer_List (INPUT-OUTPUT TABLE tPrinter_Info).
PROCEDURE Get_Printer_List
DEFINE INPUT-OUTPUT PARAMETER TABLE FOR tPrinter_info.
So the the include file looks like:
Printer_Tbl.i
DEFINE TEMP-TABLE tPrinter_info
FIELD fieldname as CHAR
FIELD userDescription as CHAR
FIELD deviceAddress as CHAR.
--------------------------------
Main Program:
{Printer_Tbl.i}
RUN Get_Printer_List (OUTPUT tPrinter_Info)
-- - - - - - - - - - - - - - - - --
PROCEDURE Get_Printer_List
DEFINE INPUT-OUTPUT PARAMETER TABLE FOR tPrinter_info.
{Printer_Tbl.i}
Printer_Tbl.i
DEFINE TEMP-TABLE tPrinter_info
FIELD fieldname as CHAR
FIELD userDescription as CHAR
FIELD deviceAddress as CHAR.
--------------------------------
Main Program:
{Printer_Tbl.i}
RUN Get_Printer_List (OUTPUT tPrinter_Info)
-- - - - - - - - - - - - - - - - --
PROCEDURE Get_Printer_List
DEFINE INPUT-OUTPUT PARAMETER TABLE FOR tPrinter_info.
{Printer_Tbl.i}
GregTomkins
Active Member
{Printer_Tbl.i} // has to appear before the first reference to tPrinter_info
PROCEDURE Get_Printer_List:
DEFINE OUTPUT PARAMETER TABLE FOR tPrinter_info. // no apparent need to make this INPUT-OUTPUT, OUTPUT should be OK
PROCEDURE Get_Printer_List:
DEFINE OUTPUT PARAMETER TABLE FOR tPrinter_info. // no apparent need to make this INPUT-OUTPUT, OUTPUT should be OK
tamhas
ProgressTalk.com Sponsor
Note, the first question you should ask yourself is, "why am I passing the TT anywhere?". The name of your table suggests that it might contain some configuration information about a printer. So, why not put this in a persistent procedure, possibly super, so that you can reference it from anywhere without passing it?
In fact, perhaps you should be considering putting all the printing logic in one module and making that persistent so that you call it from everywhere when you need to print.
Also, if you really do need to pass it (which I doubt), you should be carefully considering the mode and options, depending on version. If you pass it as output, as shown, you now have two copies. Look up BIND and BY REFERENCE so that you only have one copy.
In fact, perhaps you should be considering putting all the printing logic in one module and making that persistent so that you call it from everywhere when you need to print.
Also, if you really do need to pass it (which I doubt), you should be carefully considering the mode and options, depending on version. If you pass it as output, as shown, you now have two copies. Look up BIND and BY REFERENCE so that you only have one copy.
Well maybe you could shed some light for me. I'm well versed in programming, but new to Open Edge.
I am updating QAD custom programs. These are "standalone" in that they execute off a menu, and go away.
I couldn't find anyway of making dynamic arrays or data structures, so I thought a table would be the next best thing.
My thought was an include file with commonly used procedures - like a tool box. I'm open to other ideas!
I am updating QAD custom programs. These are "standalone" in that they execute off a menu, and go away.
I couldn't find anyway of making dynamic arrays or data structures, so I thought a table would be the next best thing.
My thought was an include file with commonly used procedures - like a tool box. I'm open to other ideas!
tamhas
ProgressTalk.com Sponsor
Working within the confines of a poorly architected system is always a problem, but there is nothing you have said that prevents you from launching a persistent procedure and referencing it anywhere in the call stack. Commonly used procedures are a natural for this use.
E.g., many years ago I had an application whose core dated literally from version 2. One of the indicators of that was that there was a big chunk of shared variables that were included everywhere to provide context information like user name, fiscal period, login, etc. Few of the values were referenced in any body of code, but they were all defined everywhere. I created a persistent procedure, launched and populated it in the menu system, and made it a super. I populated both the shared variables so that everything that hadn't been changed still worked the way it always had. But, for any new function or any function which needed any serious rework, I cut out the shared variables and substituted calls to the super. Making it a super made that particularly easy since I didn't even have to pass in a handle. The result was that I only referenced the values which the particular program actually needed and anything not needed was not defined. Much, much cleaner and something I could implement one program at a time.
Similarly, I would find programs where there were a bunch of interacting programs that needed access to some common information and logic, but only in the set of programs related to one menu choice. Put that info and logic in a persistent procedure in the top level function and make it super, but not session super, and the info and logic could be freely accessed by any of the programs in that overall function, but the logic to implement it was all in one place and the interface between programs was limited to the information which needed to be passed. Much cleaner and clearer and easier to maintain.
Encapsulate, encapsulate, encapsulate.
E.g., many years ago I had an application whose core dated literally from version 2. One of the indicators of that was that there was a big chunk of shared variables that were included everywhere to provide context information like user name, fiscal period, login, etc. Few of the values were referenced in any body of code, but they were all defined everywhere. I created a persistent procedure, launched and populated it in the menu system, and made it a super. I populated both the shared variables so that everything that hadn't been changed still worked the way it always had. But, for any new function or any function which needed any serious rework, I cut out the shared variables and substituted calls to the super. Making it a super made that particularly easy since I didn't even have to pass in a handle. The result was that I only referenced the values which the particular program actually needed and anything not needed was not defined. Much, much cleaner and something I could implement one program at a time.
Similarly, I would find programs where there were a bunch of interacting programs that needed access to some common information and logic, but only in the set of programs related to one menu choice. Put that info and logic in a persistent procedure in the top level function and make it super, but not session super, and the info and logic could be freely accessed by any of the programs in that overall function, but the logic to implement it was all in one place and the interface between programs was limited to the information which needed to be passed. Much cleaner and clearer and easier to maintain.
Encapsulate, encapsulate, encapsulate.
GregTomkins
Active Member
+1 for encapsulation and avoiding shared variables, but -1 for super procedures and balking on principle at passing TT's around. We almost never use SP's - basically, because our system is huge, 10000+ .p files, and the definition of 'commonly used' is too variable. And I don't think it's because our software is poorly architected (at least not in this respect). You can achieve encapsulation many ways!
tamhas
ProgressTalk.com Sponsor
Why does a large system preclude SPs? Indeed, I would say the larger the system, the more argument there is for PPs and SPs to encapsulate and centralize common logic and simplify interfaces. Session supers are perfect for something that always needs to be available. Function specific SPs are perfect for logic that only applies to one or a few functions.