Search results

To the container window, add an internal procedure that will accept the value from the browser which it can then pass it on to the viewer, which will itself need a new internal procedure to accept the value. Then in the browser, you can obtain the handle to the container window at runtime...

The browser will have to communicate with the fill-in through the container window, which can contains both and can communicate with both.

Yeah and I can dump my data in a garbage can too.

So because you, just one person out of the whole wide world, cannot get some ODBC connection working, the whole product is trash and should be tossed in the garbage? Man, I would hate to see what would happen if you lost the key to your front door.:awink:

You just threw "default-buffer-handle" into the mix and never explained the difference :awink:

Without reviewing Bruno's offering I came up with a hybrid that eliminates some of the IF stuff: FUNCTION RemoveItemFromList RETURNS CHARACTER (pc-list AS CHARACTER, pc-removeitem AS CHARACTER, pc-delimiter AS CHARACTER): DEFINE VARIABLE li-pos AS INTEGER NO-UNDO. li-pos =...

Hehe. Sounds like you don't like error messages. Don't blame Progress for that. Maybe you should make the frame bigger? Or the fill-in format smaller and/or make sure it's a scrolling or editor format.

What the heck is a fill-in frame?

DEF VAR cChar AS CHAR. DEF FRAME f cChar. ON ANY-PRINTABLE OF cChar IN FRAME f DO: IF NOT DYNAMIC-FUNCTION('isAlphaNumeric':U,KEYFUNCTION(LASTKEY)) THEN RETURN NO-APPLY. END. ENABLE cChar WITH FRAME f. WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW. FUNCTION isAlphaNumeric RETURNS...

There are many ways. You first have to decide how you want to block the characters you don't want - as they are entered, when the user tabs out of the field, when the user clicks the "save" button, or at the back end in the data dictionary level, such as an assign trigger or a validate statement ...

That's really the bottom line. In most cases it has a lot more to do with the developer that the tool.

Hail to ye Progressers down under! :awink:

Whew! The cavalry shows up just in time. :-)

Your "database engine" is just a fancy term for database server side execution. Of course Progress has a database "engine". All databases have to have an "engine". They wouldn't function without one. Code that updates the database is code that updates the database. Progress uses the "virtual...

An afterthought: The Progress 4gl and the various "SQL" based development environments offer different solutions to the same problems. They have gone down different paths. You may like or dislike one or the other, but it's really a matter of preference, not a matter of one environment being more...

You are of course, referring to stored procedures. The Progress SQL 92 engine supports Java stored procedures. You are correct in your observation that the 4GL engine does not, and although you did not state it, it is also not possible to "mix" the 2 engines in the same application. There is...

1) No database engine can ensure referential integrity without code. In this, the databases you mention are no different from Progress. 2) Progress stores data in VARIABLE LENGTH format. The format in the DD is DISPLAY format, not PHYSICAL size. You don't have to WORRY about physical size -...

How ironic. The complaint used to be that it wasn't "Enterprise". Guess you can't win, huh? :)

Try looking at the virtual system tables.