Questions? Feedback?powered byOlark live chat software
Bug 3313

SelectText(.., 1) jumps to next line in mle in a different way on Windows 7 vs Windows 10 10 September, 2019

Miguel Leeuwe
10 September, 2019
Product: PowerBuilder Category: PowerScript
Version: 2017 R3 Publishing: Public
Status: Closed Priority: P2
Classification: Resolution: WONTFIX
Miguel Leeuwe 10 September, 2019
Yeah, I thinks so too, 

In the end I've digged into TFS and VSS and was lucky that we at some point migrated from VSS to TFS (to later go running back to VSS again :p).
Anyway it didn't cost me too much trouble to get en new "old" version for this customer.

However I don't agree on what you're saying about "W7 not being supported anymore". 
If something worked in a determined way on W7, like let's say a command like Pos(), and then on Windows 10 it works DIFFERENTLY (being better or worse than in W7, like now you have to select a character more or less if there's an enter in the string), then I don't think Appeon can get away with simply saying "ahh Windows 10 is doing it better than W7 and that one is almost not supported anymore so we're not going to fix it".

Lucky me I'm very forgiving :)
Cheers
Chris Pollach 10 September, 2019
Hi Miguel;

  I will now close this ticket. 

  I think that the way the command works with a "zero" length that we see in PB12.7 => 2019 is correct for W10. Since W7 is basically deprecated by MS, I cannot see Appeon trying to address this inconsistency (just my guess).

Regards ... Chris
Miguel Leeuwe 10 September, 2019
(hour = our in previous post)
Miguel Leeuwe 10 September, 2019
Hi Chris,
The problem is not changing the code. If I just change the 1 to be a 0, everything works fine on both Windows 7 and windows 10.
The problem is that we have customers that would have to go through a lot of database upgrade procedures to get up to date with "our latest" version of "their old version" which are not the same. Their old version is still a year and a half older than our latest old version. (yes, I know, but upgrading and version control policies are not in my hands).
So either I try to edit PBD's, but that seems tricky or I go back in time in source safe (VSS !!!) also not a simple task and then recompile. Brrrr 
I think we can close this one, I was just hoping to see if there was an explanation for us being able to tell to hour customers (so they'll finally decide to upgrade :) )
Thanks anyway Chris.
Chris Pollach 10 September, 2019
Hi Miguel;

  I would suggest changing your App's code, as follows:

Environment  lo_env
lo_env = GetEnvironment()

IF lo_env.osmajorversion = 7 THEN
   SelectText ( ll_next_pos, 1 )
ELSE
   SelectText ( ll_next_pos, 0 )
END IF


Regards ... Chris
Miguel Leeuwe 10 September, 2019
Hi Chris, thanks for answering.

Yes, I know, but the issue is that this is the way it works in Windows 7 and now in Windows 10 the behaviour of the exact same SelectText statement causes the SelectedLine() to jump to line 2, one position of readings earlier.
An older version of our applications used to "chop up" pasted text in lines of a certain length and then insert the pasted text in normal varchar fields in the database.
(in the current versions we use blobs of course, but there's still some customers out there using our old application. They'll upgrade, but meanwhile they're in trouble).
Chris Pollach 10 September, 2019
Hi Miguel;

 Yes, I get 8 characters after the loop at line#2 using your test App (as is) on my W10 build 18362.

 I think that W10 is reporting the correct value of 8 as the SelectText is highlighting character position #8 but the cursor is now at character position #9. When you change the the SelectText() command to use "ll_next_pos, 0" the correct number 9 is displayed in the loop because you need to move the cursor to that character position in order to actually be on line #2.

 As far as I can tell, the issue is with the code running on W7. However, I would have never used SelectText ( ll_next_pos, 1 ) as the 2nd argument throws off the cursor position by +1.

Regards ... Chris
Miguel Leeuwe 10 September, 2019
FYI:
I've just done a fresh install of an older windows 10 versions that I had on a DVD. The problem already exists, so I don't think that it has to do with a windows update on windows 10.
Most probably I was still on Windows 8.1 when things worked ...
Miguel Leeuwe 10 September, 2019
Just to be clear: when I say "in a different way" I mean differently between Window 7 and 10, NOT referring to the powerbuilder versions. PB suffers the problem in all of it's versions in the same way.
Miguel Leeuwe 10 September, 2019
TestSelectText_PB2017.zip (29KB)

*Phenomenon:
PB 12.6, 2017 and 2019 deal in a different way jumping to the next line when reading positions in a multiline edit and reading the RETURN. On windows 7 it seems to consider the carriage return as 2 characters. On windows 10 too, but when doing a SelectText(charPos, 1) instead of SelectText(charPos, 0), it will jump to the next line one character read earlier as on windows 7.

Not sure if this is due to a late update of windows 10, since I think I've had this code working correctly for a few years on Windows 10. Might be a recent Update on Windows 10?

Look at the attached simple sample application to see the different way of dealing with SelectText(..., 1). Run it on windows7 and then run it on windows 10.

The workaround is to use SelectText(..., 0) instead of 1, but I'd like to know why this is happening. We have lots of customers going only now from windows 7 to windows 10.


*Reproduce Steps:
run the exe from the attached zip file (powerbuilder 2017 R3)

Remarks:
OS:
Windows 10 
Platform:
64-bit 
Database Type:
 
Database Version: