Same exact code - v13630 eventually gives a GPF; v13401 no GPF.
Both have repeatedly been recompiled and tested.
Any suggestions as to what MIGHT be involved based on Clarion changes in v13630?
The basic debug evidence so far:
Thread has standard ABC Browse/Form.
- w/ v13630, 3rd time opening the Form results in a GPF in the window init method.
- if the thread is closed prior to 3rd open of Form & restarted, the Form open count for GPF re-starts.
- same form called by a different browse will also GPF at same line.
- procedure code has been in place for years w/ child browses on new tabs the only additions.
- removing code at which GPF usually occurs just moves the GPF to another line of code.
- code in window init method is of course mostly concerned with setting control objects/properties.
How about compiling with the intervening releases ie Build 13505 and Build 13622 and see what happens?
Then you could hopefully narrow it down to a particular build and the release notes may give some clues.
I went through the release notes from each without anything obvious jumping out, but you are right, compiling with each would be better.
I know v130505 saw some ODBC driver changes affecting PROP:FetchSize that cause problems with PostgreSQL, but I had not associated that with this GPF.
Change definitely came with v13622. No idea yet in linking the GPF to something in the release notes.
v13622 release notes mention two new features that I am guess are candidates for new troubles - ASLR, DEP. Unfortunately, not the easiest to sort out for testing as these are project file settings AND the program involves 30+ dlls.
More of what I definitely know to date:
- The GPF begins with v13622.
- It involves use of a locally declared array with multiple elements used on the list of an ABC browse.
- Including more array elements in the list, gives a GPF sooner.
- A single list is the only control necessary on the window.
- Array values do NOT need to be assigned.
- No embed code is necessary.
For anyone interested, this problem can easily be replicated in the School example program. A PTSS has been filed, but I suspect there may be other instances where the problem can pop-up in post v13622 apps.
I recall in SV Discuss Clarion 11 someone with the same issue of Arrays in a Browse
Carl - Thank you. Helpful to know as it does give me some hope. I will take some time to reconsider 20+ year old code to avoid using an array.
It’s always discouraging to invest a load of time in tracking down a SV bug, create a PTSS, and then never see that the PTSS has ever been opened for review. Even when eventually fixed, just knowing someone has actually considered the issue after being reported would be nice.
Non-existent virtual handshakes make one long for the virtual dead fish handshakes of afore.
Yeah, the co-pilot had fish.
Define a local group and declare the array is over the group.
Use the group in the browse list.
This looks to avoid the GPF caused by using the array itself in the list.