This is the code I used to create a temp-table at run time using the table handle htable.
create temp-table temphand.
temphand:create-like(htable).
temphand:temp-table-prepare("templookup").
bufhand = temphand:default-buffer-handle.
Is it possible to define the table-handle temphand as an output parameter for the procedure?
i.e. create the table at run time and then pass the handle back to the calling procedure so I can display the table to the gui.
I have tried
def output param table-handle for temphand.
but this throws the compile error...
Only unsubscripted INPUT HANDLE program variables allowed in TABLE-HANDLE FOR phrase.
Is there any other way?
Thanks for the help.
As I said in my other reply, return it as a handle if there is no AppServer.
If you wantto use a TABLE-HANDLE, then define it such:
DEFINE OUTPUT PARAMETER TABLE-HANDLE hTT.
Thank you.
Sorry for the double posting.
It is now working perfectly!
That pesky FOR in my define output param line was throwing it out.
Thanks a lot!
You might want to make a brief pause in your glee at learning all these nice new tricks to wonder if you are going about things in the right way.
While PSC has given us some good tools like BY-REFERENCE in recent versions of ABL to minimize the performance impact of flinging around temp-tables all over the place, it remains that it is actually better design practice to encapsulate the temp-table, e.g., in a class, and not have its definition required anywhere but in the enclosing unit. Instead of passing it arond left and right, just use methods to access the one instance.
Multiple copies of the same temp-table not only is a good way to chew up memory, but it also presents a garbage collection problem, neither of which are an issue wwith the encapsulated instance.
Also, while it may seem very clever to do lots of things with dynamic code, recognize that it creates a major obstacle to analysis of that code. As such, I am very reluctant to use it anywhere other than in some encapsulated black box piece of the framework (if even there) because any piece of code spends a whole lot more time being maintained than it does being created and if the next programmer can't understand it and automated analysis tools can't figure out what is being accessed because of the dynamic structures, then the apparent cost savings up front can easily be lost manyfold downstream.
The problem with classes at the moment is that you can't shove them across to an appserver. Unless that has changed recently.
jmls schrieb:
Unless that has changed recently.
No change recently. The only chance you'd have would be manual (XML ?) serialization.
But I'd prefer a serialization approach in language (for ease of using and performance). But I know others around this forum will probably disagree :-)
That is something that I would LOVE to do.
Unfortunately moving to OO programming and classes with Progress would require more than me learning the ropes.
We have developers who have been here for 10+ years and they are very good at what they do and I don't think they would like the change. Also we would need some sort of training. I have seen the .NET reference and the OO reference for progress and I understand the OO stuff (from my Java programming) but the reference for .NET is terrible.
It has no actual code in any of it and makes .NET programming seem very inaccessible without some scructured training. I learn best from reading working code examples and then given the base I can then work out how it fits together and begin to read docs for it and work out more of it. (That is how I have learnt progress in the first place.)
The fact that we are in the middle of a recession means that arranging training for any of us is a no no at the moment.
Paired with this is the problems we are having with OEA in that it doesn't seem to work properly but I have arranged some phone time with one of the guys from Progress to try and help in setting it up properly.
The last thing I want is to be in a job role that doesn't move forward with the tech but there are only a couple of us (and we are fairly new) who are trying to push the rest of us forward.
We also have loads of include files that need to be added as standard so that other procedures etc... will work. I don't really know exactly how these work and again they have been around for ages. I wish people were easier to introduce change to.
XML serialization in the language that was thorough and fully controllable would be lovely, but it is also the sort of dead simple stuff which is easy to make come from generators, so I wouldn't let that get in the way of using it.
Introducing change is always a problem and being in economic circumstances which make it difficult to obtain training makes it worse. Having staff that doesn't want to change compounds the problem. But, consider the alternative ... one sees it every day in the Progress world -- applications written to standards that were current (but already questionable) 15-20 years ago still being "enhanced" and modified according to those same standards. The result is a massive underutilzation of 15-20 years of advancement in the language and a brittle application which is hard to maintain and expensive to extend.
People ... and here I mean management even more than I mean developers ... need to stop thinking of IT as a painfully necessary cost center which should be minimized and start thinking about it as a business enabler. If you were to invest half of the salary of one programmer in tools, training, and mentoring and that were to make you 5% more productive, then you have paid off that investment in a year. And 5% is nothing. 50% is easily possible.
More to the point, think of the role of the software in the business. Think of differences in the software which might make the whole organization more productive or more efficient or enable you to get business you otherwise wouldn't get or expand your offerings into new areas of business. The returns from that kind of impact absolutely dwarf the IT expenditures necessary to enable them.
And you don't get there by doing the same old thing over and over again.
Sorry for the rant, but it is the message of the times.