Thanks James. 'RI' did the trick, although we haven't decided about using it yet, since we don't want the behavior to be used elsewhere, and we might not want to risk turning it on in the pgm and then aborting out before turning it back off. But we are considering it! Thanks again.

Paula McKeever
CAI Software LLC

I neglected to mention that I cannot convert the data to string prior to loading the grid. It needs to be numeric so that it gets exported as numeric data to a spreadsheet.

Using PxP 2022. My question concerns formatting of data in numeric cells in a grid. In Format Definition, I assign a numeric variable name to my column; e.g. Cost. In my supporting program, I set the cost's format mask with

let detail_box.ctl'Column$="Cost",detail_box.ctl'row=0, detail_box.ctl'cellformat$="######0.00-"

In the PxP documentation, the CellFormat property redirects to the documentation about multi-line Fmt$ property, which says "Before being output, the number is rounded to the number of decimal places specified in the format mask." But when I test, it truncates, not rounds. (By the way, the incoming value does not exceed the mask.)

Is there a correct way of having numeric grid cell data round instead of truncate?

Thanks in advance.

Paula McKeever
CAI Software LLC

Aha. Eureka! Thanks Len!

(I wasn't sure how to word the subject line) 

In the IT editor, if I go to a particular line -- let's say the first line in a routine/method -- is there a way to have the line load at the top of the display? The line in question loads partway down the screen, and I often have to scroll down to see the entirety of a routine that I might not need to if that first line appeared at the top. (By the way, we use line numbers in our installation.)

Just wondering if there's a way, for efficiency's sake. Thanks in advance!

Paula McKeever
CAI Software LLC

That does indeed help, Stéphane. Thank you!

First time experiencing a Win 2022 server. Have PxPlus 2022 installed. The built-in Language Help (via the Help menu) does not display content on the right panel?
Might that be an issue with the 64-bit OS not playing nice with the HTML Help version? Or other?

Thanks in advance.

Paula McKeever
CAI Software

Greetings. The Data Dictionary Update pgm *dict/dd_updt: it looks as though it returns error descriptions, not error numbers. If one's code happens to call it, will checking the err variable immediately upon returning from the call contain the error number associated with the returned message?

Thanks in advance.

Paula McKeever
CAI Software LLC

We've just discovered in the documentation for [ODB] open that the open can have parameters, including CHECK_NUMERICS. (Y/N) That seems to enforce the decimal check on the write. We're going to explore this further.

Still a little fuzzy about the "Force Data Validation on Write/Update" checkbox in DD Maint; not only does the test of the first number (e.g. the "8" in 8.2) seem to include the decimal point in the count, but that first number is for the digits to the left of and including the decimal point, not the total number of digits in the entire number (scale included, decimal point excluded) like for a write to SQL. If I understand correctly, a valid max for an 8.2 is

"Force Data Validation on Write/Update": 1234567.12
[ODB] write to SQL with CHECK_NUMERICS on: 123456.12


Paula McKeever
CAI Software

This is sort of a continuation of the original post.... We created a SQL table via PxPlus's database conversion util and have been doing some rudimentary testing to see if we can figure out what kind of rules we need to fashion for defining numeric size/precision in the DD. I.e. we've been setting numeric elements and writing them to the table that's opened via the [ODB] tag.

Let's take a numeric defined as 5.2 in our DD as an example. When we created the table, it showed as
CREATE TABLE SQL_Test
(TEST_KEY varchar(6) NOT NULL,
NUMBER_1 decimal(5,2), etc.

If I set the elem to 123.456789, the write doesn't error, which is what I was expecting. When I look at the data via SQL Svr Mgmt Studio, it shows  AS 123.46 ...rounded.

What's making it round? Is it it something on the PxPlus end or the SQL end?

TIA.

Paula McKeever
CAI Software LLC

Thanks Mike; that's a keeper link for sure. Not sure what it means in terms of my question though? We're seeking to potentially use an external SQL db for our Data Dictionary defined tables, and want to make sure that when we write to those tables via our PxPlus code, that the DD definitions for the numerics are of sufficient size and decimal setting. The PxP documentation was for me, on the surface, a little conflicting, but I'm betting there's an explanation out there that will clarify what we would need to do to adapt those DD definitions.

Greetings all. Our rule of thumb with Data Dictionary numeric elements is to make them delimited, and we define them using this example in the PxPlus manual:

6.2: 6 represents total length of the field, including explicit signs and decimals, where applicable; 2 represents scaling factor or number of decimal places

So from that, we get that 999.99 is valid, but 9999.99 is too large, because the integer portion of the number is 6 minus 1 (the decimal point) minus 2 (the decimals), which is 3.

But when we consider the checkbox "Force Data Validation on Write/Update," the validation of the integer portion of the number -- using the above example -- appears to max out at 5 digits (decimal point separate), not 3. The documentation references the IOLIST directive for more detail about this data validation.

We're planning to expand our numerics so that, when exported to SQL, they are large enough to not cause an invalid number error of some kind. Does anyone know if the SQL validation follows the PxP validation rules?

I.e. if we have a 6.2 element, then it would accept a 99999.99 (or -99999.99), and by extension 999999.99 would cause an error?

Examples for illustration would be greatly appreciated. TIA,

Paula McKeever
CAI Software

My apologies. You're right; I should have said panel X has two tabs and it's X.1 that has the two controls plus the security. I will do a ticket.

Thanks Jane! So in my example... should I be thinking that it is the Y multi-line that is not behaving as it should? I.e. yes it's disabled when first drawn, but then I have code to enable all members of a particular group, of which Y and Z are part of said group. For USER (as well as MGR), Z enables, but Y stays disabled.

This was the behavior in my uber simplified test panel, as well as the existing FM panel. My test is a panel with two tabs, the first tab had multi-line Y and dropbox Z. I hit a button that does a call "*wingrp;Enable" for the only group that these two objects belong to. There are no other things, like dependencies, that might explain why Y stays disabled.   - Paula.

(using PxPlus 2020, Windows server)
Greetings. This concerns the Security property on panels. There are some particular circumstances, as follows:

* Panel X with multi-line Y and dropbox Z, initially disabled
* Panel X has several tabs; let's call them X.1 and X.2
* Panel (tab) X.1 Security has, let's say...
   * Full access for Classification MGR
   * View-only access for Classification USER (we need that view access so that the tab always draws for everyone; everyone has at minimum the USER classification assigned to them)
* The situation in which we encountered this was a file maintenance type panel, but I confirmed this happens with a panel with tabs that was not generated as FM

So if a MGR launches the panel, the two objects are initially disabled as expected. If they then navigate to the first record in the file, that executes a process that enables the objects, because for a MGR, they should be enabled.

But for a USER, we expect the objects to remain disabled, and in fact for multi-line Y, the panel Security keeps it disabled. But dropbox Z enables, and that is not the behavior we expected. (This also happens when we try assigning the security to dropbox Z itself)

I look forward to your feedback.

Paula McKeever
CAI Software LLC