One procedure I’d normally run weekly runs fine under 10.1.2 but unexpectedly quits on one of two groupup statements under each of the 10.2 betas to date. So I’m still running both versions, shifting to the older when needed. Code new to 10.2 obviously fails syntex check under 10.1.2, so needs commenting out before running therein. Labels with new labelstyle tag don’t seem to display under 10.1.2, which seems merely cosmetic. Is there any danger to their data in incorporating 10.2 features into databases that will (with just their older features) be run under 10.1.2?
As far as I can remember there has not been any change to the internal code for groupup, so this is very surprising to me. If you can produce a database that demonstrates this I would definitely like to take a look at it.
What is a “Label with new labelstyle tag”? I don’t remember any change to labels in 10.2. I don’t think the code for label objects has been touched in several years.
In theory, this should be ok. However, this is not something that I extensively tested, or really even did limited testing of, so I cannot give you an ironclad promise.
I refer to the labelstyle tags discussed in 10.2’s Automatic Form Construction. I liked the “inverted” white on black look, which obviously gets translated into different specs internally as “labelstyle” doesn’t appear on the blueprint. But creating such under 10.2 then rerunning it under 10.1.2 leaves the label invisible. I suppose it’s then white on white.
First, it is conceivable this is a hardware problem unique to my laptop, which hasn’t been charging up to battery specs, nor even charging at all sometimes without more than usual effort on my part. It’s needed an AppleCare trip for a couple months, but I haven’t found a good chance to be without it and am stalling. Laptop seems to work normally otherwise so I guess software somewhere is the more likely culprit.
Both ‘caveman’ debugging and zlog statements show the procedure gets to the line prior to one of a couple different groupup statements before unexpectedly quitting. Run in normal context it usually, but not always, quits at the first under 10.2. On passing the first it’s never failed to quit at the latter under 10.2. Under 10.1.2 the procedure runs fine There is another groupup between the two which has never crashed. I don’t know that groupup is the source of my problem but it is part of my pattern. Running under Terminal that shows my preceding zlogs then:
/Users/johnbovenmyer/Documents/Panorama dbs/Panorama files/Run Panorama X Using Terminal: line 2: 1047 Segmentation fault: 11 /Applications/PanoramaX\ 10.2.app/Contents/MacOS/PanoramaX
logout
Running in normal context sending you this would be cruel, unreasonable and illegal. The data involved is all HIPAA protected patient data and the procedure was designed to run in the middle of an automated series of procedures involving double digit databases and taking nearly an hour to run under Mojave with my 2018 MacBook Pro. Fortunately the challenges of getting it to run, pre-Instrumentation, forced me to segment the monster. I’ve managed to anonymize my data to where it should be legal and shrink the problem procedure to where I could reliably achieve a crash in a few minutes with just the parent db and two others running. They compress to 12MB which I should be able to send to support.provue.com via iCloud email. Anonymizing my data unavoidably changes the sort order of one of the groupup’d fields. So far this model has crashed only at the latter of the two normal mode crash sites. But for me it reliably crashes under 10.2 and runs (with zlog commented out) under 10.1.2. It’s been a couple weeks since I made the simplified, anonymous version so I’d best retest it and provide precise instructions before sending it. As an aside I’m well aware my code therein offers many opportunities for relational upgrades.
If it won’t crash for you I suspect a trip to AppleCare will fix it, alas possibly in trade with Big Sur related problems.
Ok, right. Those are actually Text Display objects, which is part of why I was confused. The labelstyle tag gets converted into color and background color attributes, so inverted becomes white on black background. But Panorama X 10.1.2 doesn’t support background colors, so you just get white text with no background.
Ok, let me know.
I’ve emailed test databases and directions to support@provue.com from my iCloud email so Mail Drop can deliver the attached .zip file.
I’ve rethought the procedure that was working in 10.1.2, but quitting in 10.2. I coded the seemingly problem part differently. Goal was to input various numeric subtotals from one db into another. Previously I grouped by field, totalled the numeric field then looked up from that summary level. Then I’d remove summaries, group by a different field but otherwise repeat. In 10.2 it seemed to quit not on the first, but on a subsequent groupup. The workaround was to not group the database but rather to use 10.1’s summarytable() function to collect the subtotals into text arrays then arraylookup from them. Simpler and faster, once I overcame mental inertia to consider it! It worked in both versions.
Once I’d fixed my index problem I tried my workflow’s main sequence of procedures under 10.2. I’d been running it under 10.1.2 because it quit at the index problem before. I found a couple other places, in other dbs, it would quit under 10.2. Always on a groupup statement as part of a similar data transfer. I rewrote them as well using summarytable() and for the first time saw the workflow run to completion under 10.2. A 66 minute success. Next, start substituting relational code to speed it up…
However, I still think there is a problem, either unique to me or new to 10.2, leading to unexpected quits. I’ve sidestepped it, but if it wasn’t unique to me, I hope the files I sent help solve it.