Bizarre problem with %df & %^rf

This message follows on from my previous one about %dl, which on the basis of further investigation provisionally seems to have been exonerated. Certainly as far as the call stack anomalies are concerned I have ruled it out completely. I have now isolated the part of the code where these call stack anomalies originate. They are associated with the callback from a %^rf input field (which has a %df to allow spin control). The bizarre thing, that I have established after quite a lot of trial and error, is that whether or not the problem occurs depends on how I edit the contents of the input field:

• If my first edit uses the spin control, things go wrong
• If my first edit edits the field directly, this works, and so do subsequent uses of the spin control

On the basis that the same code is invoked regardless of how the input field is edited, this seems to me be pretty strong evidence for a compiler bug rather than a programming bug. Can you speculate as to what might be going on - it might help me in trying to isolate the problem in a manageable size chunk of code.

Andy

Sorry but I cannot throw any light on this.

Short and to the point! Paul, I have spent much of the last week observing unexpected program behaviour that is probably the incomprehensible I have ever encountered, and it all kicked off when I successfully (?) rebuilt my program as /checkmate apart from one module built as /debug. I have been changing code as well, so I started out assuming I had introduced a bug in my own code. I haven't entirely ruled that out, but nor am I entirely convinced yet that I'm looking at a compiler bug. It occurred to me yesterday that there was a third possible explanation: can you see any way in which the 'mixed mode' linking that I posted about recently might be responsible for problems?

Andy

The linking environment is designed to permit the linking of objects with differing debug modes so this should not be a problem. In fact, as noted earlier, you can vary the debug state from one routine to another within a single file by using the OPTIONS directive.

That's what I expected, but thanks for confirming it. I shall relegate it to the bottom of list of suspects.

Paul,

I appear to have established this morning that this problem only occurs with the mixed /CHECKMATE build, and not with the /DEBUG or /RELEASE builds. To be more precise, it occurs immediately with the mixed /CHECKMATE build, and I have yet to manage to trigger it with the other two builds. It occurs whether I run the app under control of SDBG within Plato, or standalone. I get no error messages, just unexpected program behaviour.

When I edit the number in the %^rf field, whatever problem is triggered behind the scenes leads to further edits changing the number in the edit box without invoking the callback chain. It also disables the OK and Cancel buttons - the only way to close the parent window is the X at top right. Mindful of your warning about the limitations of SDBG for ClearWin programs, I have upgraded the code so that my call stack monitoring routines produce a log file of every routine push and pop. This shows that the callback chain is not terminating correctly when the problem occurs. I have no idea where control is passing to - if I try and step through the code using SDBG, I end up in a window of assembler code.

So ... I appear to have shot myself in the foot by building the /CHECKMATE diagnostic facilities into my app. I am going to try and cut the app down to a manageable size and send it in.

Andy

Hi Paul,

I have just emailed you a zip file with a cut-down version of the app that illustrates the problem. Please keep me posted on progress.

Andy

Repeated attempts to get any sort of feedback on my bug report have failed. I thus have no idea, one month later, whether anyone at Silverfrost has even reproduced the bug I spent half a day producing cut-down code to illustrate, let alone tried to fix it. I am thus resorting to venting my frustration in the forum for other users to look upon and compare notes with.

I've always paid annual maintenance (well, my company has) since I became a Salford customer, about 12 years. I could point to one or two occasions in that time when the service it bought was less than exemplary, but equally I could point to many more occasions when the reverse was definitely the case. Up until the point when Silverfrost became responsible, anyway. However, on the basis of this current experience I shall definitely be reconsidering paying for annual maintenance next year.

Am I being unreasonable in thinking that a brief email along the lines of 'Thank you for the code you submitted. We have reproduced the bug you reported. We anticipate fixing it within a timescale of ..., and will inform you when we have done so, or in the event of the timescale slipping' is not too much to ask for?

Am I being unreasonable in thinking that a month is a reasonable timescale within which at least to have made some progress on the matter, even if not to have fixed it, and to have provided some feedback either in the related thread on the forum or by email?

Andy,

Can you post the problem in a very short form that some other user can help with? One of the ways to deal with the problems is to find a workaround. For example, consider the following code:

    WINAPP  300000,500000
    OPTIONS (INTL)

C PROGRAM ABC IMPLICIT DOUBLE PRECISION (A-H, O-Z) INTEGER MODE(3) COMMON NFL INCLUDE <WINDOWS.INS>

    MODE(1)=1
    MODE(2)=0
    MODE(3)=0

10 CONTINUE IA=WINIO@('%ca[Data entry screen]&') IA=WINIO@('%co[check_on_focus_loss]&')

   IA=WINIO@('Real variable%2ta%rf[INITIALLY_BLANK]%lc&', R,MM)
 
   IA=WINIO@('%nl%nl%ob[named_l][Plotting mode]%nl%3`ga&',
 +            MODE(1),   MODE(2),   MODE(3))
   IA=WINIO@('%rb[RB 1]&',         MODE(1))
   IA=WINIO@('%nl%nl%rb[RB 2]&',   MODE(2))
   IA=WINIO@('%nl%nl%rb[RB 3]&',   MODE(3))
   IA=WINIO@('%nl%nl%cb&')
   IA=WINIO@('%5nl%cn%6`bt[&Quit]')
    WRITE(1,*) R, MODE

    GO TO 10
    END

Sorry, it's FTN77 really, and it's a badly-behaved program that needs the Task Manager to close down. Anyway, it points to something dodgy with %rf. In this case, altering the setting of the ganged radio buttons clears the %rf box - and it shouldn't. This is dead straightforward %rf, with no debugging stuff. It has been broken since FTN77, and is still broken in the latest FTN95.

So, what's the workaround? The answer is to put the radio buttons first! Then, the box stays empty while you are fiddling with the radio buttons, or even if you have data in the %rf box and it clears, then see it as it is later on in the window. A muttered curse doesn't help, but at least it stops you entering zero!

But anyway, %rf is definitely a curate's egg (good in parts).

Eddie

[small]Eddie Bromhead wrote:[/small] This is dead straightforward %rf, with no debugging stuff. It has been broken since FTN77, and is still broken in the latest FTN95.

Hi Eddie,

Good grief. I played with your code last night, in the wee small hours. That's rather worrying. At least it seems it's not the data getting trashed, *just *the display 😉 :rolleyes:

I'll play with it some more (because I haven't reordered the rf and rb controls yet, and I don't understand your description in the paragraph about the workaround).

You say this has been around since FTN77. That's a very long time to be sitting on such a simply-demonstrated bug, and it predates the advent of Silverforst by many years. Surely you reported it? What happened?

Hi Andy,

Sorry my explanation wasn't clear. If you start the form with a %rf, then go on to have ganged radio buttons underneath, the user expects to enter a value into the %rf box, then go on to set the radio buttons. If the form is re-ordered, the user expects to set the radio button, then enter the value ... which doesn't then clear when the 'OK - close the form' button is pressed. Should the user go back up the form to change the radio button setting, the %rf box will, of course, clear - but the user has a chance of seeing that and correcting it. They may, indeed, imagine that it is intentional behaviour - odd behaviour, but intentional. Where the %rf comes first, the user's eye has moved on from there when they go on to select the radio button state, and the chances are the clearing of the %rf box will not be detected. It's a question of perception, not changing the behaviour of the code.

I thought that the data did get trashed. Ah well, must have forgotten - that particular oddity has been around a long time.

Eddie

Hi Eddie,

Thanks - I understand exactly what you mean now. Reordering the controls doesn't prevent the aberrant symptom, but it does reduce the likelihood of it occurring, and increase the likelihood of it being noticed if it *does *occur. So not really a workaround, then - just damage limitation.

I think the issue of whether or not the data gets trashed is pretty critical. If it does, the importance of the bug goes up by an order of magnitude. Last night, I thought it did at first, then I decided that I was getting confused between the value getting reinitialized every time the window is opened, and apparently nuked when the radio button setting was edited. I will look more closely again tonight.

I remain morbidly curious. Did you ever report this bug to Salford? If so, what happened? If not - why not?

Andy

Andy,

You were right - the data isn't trashed, only the appearance of the box contents. I'm sure I put the info up on the Silverfrost forum in about October last year. Prior to that I thought I was doing something wrong. The box only empties if it is set to be 'initially_blank'.

One of the points to my interjection is that since it doesn't happen with the corresponding integer box (I think) then it means that there is something wrong with %rf, and your (original) problem is likely to be a symptom of some underlying more extensive malaise.

Eddie

[small]Eddie Bromhead wrote:[/small] *Andy,

Can you post the problem in a very short form that some other user can help with? *

Eddie,

Practically speaking, I fear not. For a number of reasons; not least that the code needs to link to some external DLLs, and that I still had 1200 lines of code left when I stopped hacking my real code down (after the best part of a day) and submitted the result to Silverfrost. I stopped trying to cut it down further, because the symptoms were starting to show signs of going away.

I have no idea what the shortest possible code fragment is that would illustrate the problem. I'm sure it must be at least an order of magnitude shorter than the code I submitted, but to get there would entail spending a lot more time on the issue - and that's assuming I can get there from where I currently am.

I'm not even sure whether the functionality that the external DLLS bring to the code is necessary or not. The first thing I would need to do would be to try and eliminate them. Depending on what reponse if any I get from Silverfrost, and how soon, I shall spend a little time here and there trying to to just that.

Thanks for your interest.

Andy