|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Apr 17, 2019 11:43 pm Post subject: Odd behavior using %ob/%cb |
|
|
The following code will cause the second %ob construct to be made "oddly".
The root cause is the %ff%nl that immediately precedes "Second boxed line of text". Remove this, and it looks exactly as one would expect.
Code: | use mswin
integer i
i = winio@('Text Line 1%nl&')
i = winio@('%1.1ob[named_l][This is a text box]&')
i = winio@('This is a boxed loiine of text%nl&')
i = winio@('%cb&')
i = winio@('%ff%nlIntermediate Text%ff%nl&')
i = winio@('%1.1ob&')
i = winio@('%ff%nl&')
i = winio@('Second boxed line of text%nl&')
i = winio@('%cb&')
i = winio@(' ')
end |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Apr 18, 2019 6:52 am Post subject: |
|
|
I have made a note of this behaviour. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Apr 18, 2019 1:46 pm Post subject: |
|
|
Bill,
I did think for a minute that it might be the Oirish spelling of 'loiine'!
It seems to be the result of %ff in a box immediately after opening it with %ob. Put any other control in, for example a %bt, then the box happily accepts %ff. I'm not actually sure what the %ff does in the context where it messes up the boxes.
Eddie |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Apr 18, 2019 2:00 pm Post subject: |
|
|
Eddie,
Umm, yeah, that IS what does it, as I said.
I stumbled across this while re-arranging what would be the contents of the boxes.
And, I knew that the %ff%nl was "not needed". It just happened to be there.
All that said, there are two thing to note. First, regardless of the right-ness or wrong-ness of doing it this way, it was unexpected, and second, if this cannot be remedied, then a note of it needs to be made in the documentation.
It took me about 2 hours to find it. I hope that no one else need do that again. I've moved past it.
Bill |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Apr 18, 2019 2:31 pm Post subject: |
|
|
With respect, Bill, you said it was %ff%nl (see quote) - and it's just the %ff that does it. Perhaps that qualifies me for the pedantry award this week.
Quote: | The root cause is the %ff%nl that immediately precedes "Second boxed line of text". Remove this, and it looks exactly as one would expect. |
%nl does have a place after %ob, and that works. %ff works anywhere in a box except immediately after %ob. There must be an answer to the question why nobody discovered it before - a question I often ask when even more esoteric bugs are discovered.
As far as documentation is concerned, we live in hope. Not only that, even if it had been documented, would you or I have found it in as little as 2 hours?
It seems that the solutions could include (1) to forbid %ff immediately after %ob, (2) to ignore it, (3) to make the case one of those that is checked using the /CHECK switch for checking Clearwin+, and extend that to the 32 bit version of FTN95.
Eddie |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon May 06, 2019 8:54 pm Post subject: |
|
|
%ff jumps pas all controls existing controls.
Since it's called in a %ob I assume that means all the controls in the box.
Since there are no controls when it is called it's logical that thre's no need for it to be there no ?
And the fact that there are no controls can explain the odd behaviour as there's nothing for it to jump past !
Probably a simple 'for i=1, nctrls jump past next ctrl,' in the %ff code somewhere, where nctrls= 0 !
That old man zero, don't you just love him. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|