Tyleulen

I am observing some confusing behavior using ProIV Kernel Version 7.1.58.3-PR and Postgres 9.4.

 

I am doing a calculation at full precision, 6 decimal places, I can monitor the value both before and after the file write within ProIV, and it does indeed have all 6 decimal places.  The postgres table is set to store only two decimal places.  Everything in Postgres' documentation says that if I pass more than the set number of places, it will round off the value to the correct precision.  What seems to be happening though, is that when ProIV sends the UPDATE command to Postgres, it is only passing two decimal places, not the full six.  Not only is it not passing all of the digits, it seems to be truncating the number at two decimal places, not rounding it off at all.

 

Is there any way to control this behavior?  I don't think there is any way to directly tweek the SQL command that ProIV is sending to the database, but is there perhaps a setting that will tell it to include full precision?

I have a report function that refuses to line up correctly with the pre-printed forms if it goes past the first page. The problem seems to be in the text file that ProIV is generating. On the first page, there is a blank line followed by the page header statics, on the second page there is a ^L followed by the page header statics. The ^L is the page break, and it is in the correct place, but the blank line that appears at the top of the report does not appear after the ^L, so all the pages after the first are shifted up in relation to the form they are printing on.

So, the question is, is there any way to add a line feed in on the second and subsequent pages before the page header, or is there any way to add a blank line to the text file being sent to the spooler after the ^L character?

We are using ProIV 5.5 on a Solaris server (SunOS 5.9) and spooling the printouts to Okidata printers emulating EpsonFX.

I have run into a couple of "features" and I am left scratching my head.

I have a combo box that calls a global screen to allow the user to search. The problem arrises in that ProIV seems to have a "feature" that even though the global screen has no parameters, and there is no map associated with the combobox, it still trys to "help" by starting the screen scrolled down the list to where the default value is. So, since the default is 'ALL' and the data is mostly numeric, it displays the bottom of the list instead of the top.

In my effort to get around this "feature" I altered the logic so that it nulls the field On Focus, then restores the default value in Lost Focus if it is still null. This works ok as a cludge, my list now displays from the top, but it introduces a new problem: If the user shift-tabs through the field it executes the On Focus logic, but not the Lost Focus logic! So, the user can leave the field blank. If I mark the field as Must Input then the Lost Focus logic never gets updated and you get stuck in the field.

So, is there any way to suppress the "feature" that trys to sort the list, or is there anyway to force the Lost Focus logic to execute on a shift-tab?

At this point, I am considering leaving the default set to null and just have a display only field over the top of the actual input field that says 'ALL' Please tell me there is a better answer.

Edit: ProIV version 5.5b524
VIP version 5.5923

ProIV 5.5 with VIP

Is there a way to put a non-printing character into the Button Caption field of a Radio Group?

I would like to lay out 3 buttons next to each other on the same row, and label them at the top of the columns, but there doesn't seem to be a way to not have lables next to each individual button. The best I have managed is to use a . as the caption and then set the foreground color to the same as the background. This is not an ideal solution since ProIV still highlights this invisible label each time you click on a button. Is there some ascii code non-printing character I can use to have no caption?

In a report function is when you mark a field for vertical total is there any way to use that total in the logic of the report? I assume there is some sort of internal collecting variable. Is it accessable?