View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sat Aug 01, 2020 2:02 pm Post subject: |
|
|
Apologies. I have updated the file. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sat Aug 01, 2020 2:54 pm Post subject: |
|
|
These are the compile options for this routine (and 99.9% of everything in the /CHECKMATE compilation).
Quote: |
BINARY;CFPP;CHECKMATE;DUMP;ERROR_NUMBERS;FPP;HARDFAIL;IGNORE;
IMPLICIT_NONE;LIST;NO_COMMENT;PERSIST;SAVE;UNLIMITED_ERRORS;WIDE_SOURCE;XREF;
ZEROISE;
|
|
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Aug 02, 2020 2:55 pm Post subject: |
|
|
Here's the top part of the .MAP file after linking. Both /CHECKMATE and /RELEASE are identical as far as this is concerned..
Quote: |
Linker Map of f:\cmasterf95\CHECKMATE\WIN32\C-MASTER.exe Sun Aug 2 07:31:59 2020
Image base = 400000 Image align = 1000 File align = 200
Stack = 3200000 Heap = 100000
|
All my link steps use the default values (4 separate programs). |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sun Aug 02, 2020 3:20 pm Post subject: |
|
|
There seems to be a least one more file missing...
TYPE_DEPENDENT_INTERFACES.INS
I have not checked if there are others missing. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Aug 02, 2020 4:28 pm Post subject: |
|
|
I had forgotten how deep the includes went.
I think I have them all now.
Thanks for hanging in for me! |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Aug 02, 2020 5:41 pm Post subject: |
|
|
Paul, I think I have found the underlying cause of this problem. Why removing the reference to the routine allows it to (mostly) work, is still a mystery.
I created my own routine to perform both the SET_BROWSE_FOR_FOLDER_INITIAL@() the browse for folder function long ago. It turns out, there were problems with the arguments to the library functions. They were type'd correctly, but not "formed" properly.
My routine is supposed to take the path and run the SET_BROWSE_FOR_FOLDER_INITIAL@(). The window handle is also passed to the routine, but there seems to be a potential issue here (see below). The browse_for_folder1@() is run using the logical result to see if the user had selected.
The initial search folder (in some instances) was formed from concatenation of a trim() of a the path string, then a CHAR(0). What this did was to arbitrarily limit the response by the user to the number of characters up to the NULL character. If you chose a folder with a longer name, I get a Floating Point Stack fault. This may have been part of my initial problem report (of long ago).
In the example I was running, the initial string was long enough to accept the new selection once the selection could be made.
While the browse_for_folder1@() function can take a zero for a window callback, I had set a local variable to what I thought would be the active window handle (call back). However, the actual return value from CLEARWIN_INFO@('CALLBACK_WINDOW') was the handle of the window I had just exited. Therefore, the handle was invalid. This appeared to cause other problems that I had not yet posted about. I added a function call to ISWINDOW() in the routine to verify the validity of the handle, and use a zero if the handle is not valid.
I re-enabled the ALLOCATE in the "bypased" routine, re-ran my test and had no problems encountered whatsoever.
I have scanned my other code for similar //CHAR(0) occurrences to make sure this doesn't happen again.
So the "bypassed" routine occurred BEFORE the call to my function. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sun Aug 02, 2020 7:18 pm Post subject: |
|
|
Bill
Do you still want me to look at your code? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Aug 02, 2020 9:15 pm Post subject: |
|
|
Paul, no, I think I'm good. I did something "not intelligently", and have corrected it, thanks to your hints about memory allocation. I have added this to my list of things to do (or not to do).
Bill |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Aug 02, 2020 10:29 pm Post subject: |
|
|
I missed stating that the original problem has not "gone away". The fact that it exists in /CHECKMATE and not in /RELEASE means it is not important enough for me to pursue it, nor have you pursue it. My further problem discovery and fix is just a happy coincidence.
Should this pop up again in both compilations, I'll be posting again. |
|
Back to top |
|
|
|