screen buffer access

[mpowell_esq]

If you follow the ADM route, you KNOW where the bugs will be and where your code falls down.
This limits the time wasted trying to locate where the actual error is situated. By following the framework of the ADM & ADM 2, the process is shortened. You are not limited to a single developer either, ALL progress people will have their own experiences of little 'features' that arise and know how to cure them. Which is why following the ADM is a good method to development. Everybody is then 'singing from the same hymn sheet'. Allowing external folk to be introduced more easily. It would be possible then to out source to tin-su-do or wherever else the labour is more economical.
OpenEdge works because it 'has the EDGE over competitors to OPEN solutions'

 

[KnutHandsome]

RE "Use our framework - it'll **** up your code!"

How can it do that? If you are using the framework You are applying the code, therefore YOU are doin the code that is ****** up, you are the developer.

I was commenting on your choice of words, not the framework, o literal one.

The elephant analogy is know and used

The 'elephant analogy' involves blind men identifying an object, not bloody eating it, foolish boy.

Hence M$ & Windows, the product HAS NEVER been stable, so there has never been a chance to improve it. The same old hash keeps becoming churned out. Based origionally on the 9X kernal, then more 'FEATURES' / BUGS with the rewrite into XP and other.

The same old hash keeps being churned out about M$ and how rubbish it is. MS makes some great products, and Windows is pretty stable these days.

p.s I should be working for PSC, I promote the excellent product whenever I can, which is always!!!

That we can agree on, as far as PSC is concerned,you are a little ray of sunshine.

 

[KnutHandsome]

OpenEdge works because it 'has the EDGE over competitors to OPEN solutions'

Oh, so that's what it means? It sounds like one of those "let's think of a pointless brand name then we can decide what it means" marketing decisions.

I have to say, I think 'OpenEdge' is one of the stupidest, most meaningless product names I've come across.

 

[smapdi636]

Problem is, its more likely to have an impact on the Linux and MY-SQL environment, which I'm not terribly interested in.

Do you mean as far as - it's more of an open-source thing rather than commercially/business-oriented like Progress?

I'm asking because for both development & deployment, Windows works fine as well (as does OSX). I used Windows & Apache (and MySQL as you said).

However I guess theoretically Rails should be able to work with Progress via ODBC. Works with PostgreSQL & Oracle.

I keep telling myself that one of these days I'm going to try it with Progress. Someone else had the same idea but also hasn't followed up: http://wiki.rubyonrails.com/rails/pages/Progress. I only messed with Progress' ODBC stuff once many moons ago - that's holding me back.

 

[KnutHandsome]

Do you mean as far as - it's more of an open-source thing rather than commercially/business-oriented like Progress?.

More because the (many) people singing its praises tend to come from the Open Source movement, so I'm not sure how much of an impact it will make on the commercial Windows world, which is where I want to be professionally.

Also, the examples I've seen tend to rely on command line use, which I hate, preferring to click buttons and drag-and-drop the easy way.

Oh, yes, and I am already competent in one technology that nobody uses.

I'm asking because for both development & deployment, Windows works fine as well (as does OSX). I used Windows & Apache (and MySQL as you said).

That's useful info, thanks, I would love to get into a technology which would make inroads into the MS world, and where I wouldn't be years behind (eg. SQL Server, .Net), having spent too much effort on Progress.

Trouble is, I don't have the time to study the established technologies, let alone the ones that might take off.

However I guess theoretically Rails should be able to work with Progress via ODBC. Works with PostgreSQL & Oracle.

I keep telling myself that one of these days I'm going to try it with Progress. Someone else had the same idea but also hasn't followed up: http://wiki.rubyonrails.com/rails/pages/Progress. I only messed with Progress' ODBC stuff once many moons ago - that's holding me back.

Personally, I think your time (Progress-wise) would be better spent completely avoiding ODBC (which has a reputation for being slow and difficult), and looking into the web service alternatives available with OE10.

Also, if you are going to use SQL, it doesn't make sense to use Progress, which isn't really built for that.

I should point out, I haven't done that (web service/open client/xml stuff) myself apart from read the docs, but it is one of the major selling points of OE10.

It would be an interesting experiment to provide the beginnings of a framework for integrating ROR with 4GL routines via services, and would certainly give you a rare skillset, though whether or not it would be sellable for some time is another matter...

 

[smapdi636]

Oh, yes, and I am already competent in one technology that nobody uses.

A-ha-ha! Tell me about it. You'd think I'd have learned my lesson.

Also, if you are going to use SQL, it doesn't make sense to use Progress, which isn't really built for that.

Ya I think Rails would be using all SQL behind the scenes given an ODBC connection to Progress so maybe the exercise has less value than I imagined.

I should point out, I haven't done that (web service/open client/xml stuff) myself apart from read the docs, but it is one of the major selling points of OE10.

I'm definitely interested in learning more about OE10 - just haven't gotten there yet.

 

[KnutHandsome]

Oh, yes, and I am already competent in one technology that nobody uses.

A-ha-ha! Tell me about it. You'd think I'd have learned my lesson.

More on the runaway success of Progress here...

http://forums.programming-designs.com/viewtopic.php?pid=3423

[Scroll way down ]

 

[Casper]

The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors. The popular search engines Google, MSN, and Yahoo! are used to calculate the ratings

Well I argue if this is a good way to measure quality and viabiltity of a language.

It does say something about how much choice you have if you're looking for a job though.....

That's useful info, thanks, I would love to get into a technology which would make inroads into the MS world, and where I wouldn't be years behind (eg. SQL Server, .Net), having spent too much effort on Progress.

If you have any change, start by getting yourself in Integration projects. Lot's of stuff to learn there concerning other languages and common standards....

Casper.

 

[KnutHandsome]

Well I argue if this is a good way to measure quality and viabiltity of a language.

It isn't, and I didn't see an explanation of how they derive their findings, but it was more of a light-hearted post, not really intended for serious consideration (although I suspect it has some merit). I just stumbled on it after making the previous post.

If you have any change, start by getting yourself in Integration projects. Lot's of stuff to learn there concerning other languages and common standards....

What are Integration Projects? Do you mean integrating with popular business/os apps (eg. Microsoft Office/Dynamics/Sharepoint whatever), or is it a technical term?

 

[mpowell_esq]

Re: Elephant analogy

It is an analogy Armish boy. Look at it objectively - I AM NOT blind so I am unable to relate to that instance. I can however relate to breaking an objective down into instances to realize a solution. It is an analogy NOT real, therefore the method that realizes a solution is the the most productive and appropriate method to pursue. Armish boy it is about realizing a solution and delivering. Development is NOT binary.

 

[KnutHandsome]

Re: Elephant analogy

It is an analogy Armish boy. Look at it objectively - I AM NOT blind so I am unable to relate to that instance. I can however relate to breaking an objective down into instances to realize a solution. It is an analogy NOT real, therefore the method that realizes a solution is the the most productive and appropriate method to pursue. Armish boy it is about realizing a solution and delivering. Development is NOT binary.

OK. Well, I reckon we both think along the same lines.

Later, bud.

 

[Casper]

Oh well, sorry I jus invented a word probably .
I meant to say projects which involves for example integration with other applications like office for instance.
Or different interfaces like HTML, .NET, Sonic, XML,PHP/SQL.

Everything regarding interfacing with other apps/languages gives you a chance to learn stuff beyond Progress....

Regards,

Casper.

 

[KnutHandsome]

It isn't, and I didn't see an explanation of how they derive their findings

Apparently it's very in-depth and scientific:

They google "[language] programming", and record the number of hits.

http://www.tiobe.com/index.htm?tiobe_index


Original page here:

http://www.tiobe.com/tpci.htm

 

[it@flude.co.uk]

Watching it spiral out of control ........

In answer to the original question, no you can't pass a buffer to a record so that you can access the screen-values of the record via the buffer. The screen-values are independant of the buffer as they have not yet been written to the buffer. They are frame-dependant, but you don't want to be using frames/screen-values in generic routines.

What you can do, however, is to generate a string containing the screen-values of the fields in a frame and use that string to pass screen-values. It's not as elegant as a buffer, but you could use it to fill a temp-table record and use that for your processing.

So, an example noddy program to illustrate:

def var field1 as char no-undo.
def var field2 as char no-undo.
def var field3 as char no-undo.
def var field4 as char no-undo.

def var h_field as widget-handle extent 10 no-undo.
def button btn_ok label "OK".

form field1 field2 field3 field4 btn_ok with side-labels 1 down three-d frame f1.

/* Use an array of handles to make processing easier - you could use a temp-table instead, not much difference */

do with frame f1:
h_field [1] = field1:handle.
h_field [2] = field2:handle.
h_field [3] = field3:handle.
h_field [4] = field4:handle.
end.

/* Build up the string using the generic array of handles */
function f_screen_values returns char:
def var frame_loop as int no-undo.
def var return_value as char no-undo.
do frame_loop = 1 to extent (h_field):
if valid-handle (h_field [frame_loop]) then
return_value = return_value + h_field[frame_loop]:screen-value +
chr(9).
end.
return return_value.
end function.

on choose of btn_ok in frame f1 do:
message f_screen_values () view-as alert-box.
/* or do whatever you want with it */
end.

view frame f1.
enable all with frame f1.
wait-for choose of btn_ok in frame f1.

 

[Casper]

Watching it spiral out of control ........
[/qoute]

:lol: Yeah that happens sometimes

 

[KnutHandsome]

The out of control ones are the best ones.

 

[tamhas]

Personally, I think your time (Progress-wise) would be better spent completely avoiding ODBC (which has a reputation for being slow and difficult), and looking into the web service alternatives available with OE10.

Also, if you are going to use SQL, it doesn't make sense to use Progress, which isn't really built for that.

You should try some of the more recent versions of Progress. The JDBC/ODBC drivers are way more advanced than they were.

 

[tamhas]

More on the runaway success of Progress here...

http://forums.programming-designs.com/viewtopic.php?pid=3423

[Scroll way down ]

I wonder where they get their numbers. One of the things we heard about at Exchange this year was that there were 100,000 sites using Progress and 5 million users. Either some of us have been way productive or there must be a few Progress developers out there somewhere.

 

[smapdi636]

In answer to the original question, no you can't pass a buffer to a record so that you can access the screen-values of the record via the buffer. The screen-values are independant of the buffer as they have not yet been written to the buffer. They are frame-dependant, but you don't want to be using frames/screen-values in generic routines.

I wasn't hoping for access to the record buffer ... What got me started on this is the way the Progress documentation refers to the screen buffer (section 9.5 of the Programming Handbook, "Data-handling Statements"). It reads, "Progress stores data in various locations--a database, a record buffer, a screen buffer, etc."

I imagined the screen buffer as an object in memory ... basically as a discrete mirror image of the record buffer. If this is how it worked, I imagined it might be possible to get a handle to that buffer. If that was possible, my problem might have been "solved".

Barring the screen-buffer/handle idea it seems like I might as well go back to passing an input param for each field. Given that the thread exposed a flaw in my logic anyway (tight UI/DB coupling), input params now make more sense although I think I should try to code-generate them.

 

[KnutHandsome]

I wonder where they get their numbers.

Dubious resource. More info a few posts up.

http://www.progresstalk.com/showthread.php?p=327226#post327226http://www.progresstalk.com/showpost.php?p=327226&postcount=33

One of the things we heard about at Exchange this year was that there were 100,000 sites using Progress and 5 million users.

I wonder where they get their numbers. It woud be nice to have solid info from Progress/independent resource on existing base, and importantly new takers (I've appreciated your occasional posts on the subject elsewhere btw.).

It's easy to get disheartened when you look for vacancies and see very few new openings in your area - I mean miniscule compared to the big guys - while at the same time salaries do not seem to reflect a premium for a niche skill.

I suppose 'niche' is rather different in this case to 'sought after'.