Notepad++ File Status Auto-Detection not working
-
No, seems to work for me
But the evidence that two users using windows xp having the same issue can’t be ignored.
Cheers
Claudia -
Thank you :)
-
I found the third user with a problem. Here too someone wrote.
https://notepad-plus-plus.org/community/topic/14902/v7-5-2-and-v7-5-3-file-status-auto-detection-don-t-work -
Curious, despite the autodetection function there is another function with similar functionality.
It is under View->menu and is called Monitoring (tail -f). (the eye icon on toolbar)
If you activate this and do some changes do you see the updates?Cheers
Claudia -
So, nothing happens.
In addition, after activating Monitoring (tail -f), it’s impossible to print anything in Notepad ++. The text does not print, as if the readonly mode is turned on. -
The text does not print, as if the readonly mode is turned on.
That is correct and expected behavior. The function is the only one who can updated
the file content once it gets triggered that file content has changed,So it looks like there is a general issue with file modified notification mechanism.
Ok, I have another old laptop and I will install windows xp and do retesting.
Will take some time.Cheers
Claudia -
Well, Thank You very much for your help! :)
-
ok - can confirm reported behavior.
Last working version seems to be 7.5.1.
I checked changes from 7.5.1 to 7.5.2 but couldn’t find any hint about the offending source part.
This leads to the assumption, that switch to VS2015/VS2017 might be the root cause.
As far as I know XP compatibility must be set explicitly in VS2015/VS2017 projects
and it looks like it isn’t. At least I don’t find any hint it is set.Sorry, but that’s as far as I can go - without VS debugger I can only assume this is it.
Cheers
Claudia -
<PlatformToolset>v140_xp</PlatformToolset> is used, so build should still be compatible with Win XP SP3.
-
thank you for clarification - I was searching for v120_xp but in retrospect it makes sense
that it is called v140_xp if using a new toolset.Any idea what might cause this behavior?
Cheers
Claudia -
Hi, @claudia-frank, @chcg and All,
I just confirm the bug : the File Status Auto-Detection mechanism does not work, since the
v7.5.2version, on my Win XP SP3 platform ?!Cheers,
guy038
-
Maybe we can bisect the problematic range, starting with testing te artifacts from:
https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1635
to see if this also happens with the appveyor images.And then maybe
https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1582/ -
this is the last working one
Language menu and Style configurator sorted alphabetically and use the same language name in the Style configurator as the language menu.
https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1526
this is the first which breaks it
Switch to VS 2015
https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1530
There were no build from 1.0.1527 to 1.0.1529 due to errors.
Cheers
Claudia -
But https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1526 is a Pull request #3726 build, so not a direct successor of Switch to VS 2015 (https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1530)
That would be https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1521,
with
https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1527
https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.1528failing.
-
sorry, but I don’t get your point.
I would assume that a build with a lower build number is never a successor of a build
with a higher build number.And what is your concern about the results I’ve posted?
Cheers
Claudia -
@Claudia-Frank The builds at appveyor not just contain the trunk checkins, but also pull requests which might contain something totally different. Sorry, I meant predecessor.
I created a branch from the 7.5.1 tag and modified the appveyor config to build VS2013 vs. VS2015 on the appveyor image 2015. So this should reveal if already the switch to VS2015 is causing the trouble.
See https://ci.appveyor.com/project/chcg/notepad-plus-plus/build/1.0.114, build from https://github.com/chcg/notepad-plus-plus/commits/winxp_autodectection_investigation2
Since the checkin of the json parser(https://github.com/notepad-plus-plus/notepad-plus-plus/commit/b033d907b29f42f570c21b0bfc0ac60c257f08c4) it is no longer possible to build with VS2013 due to the lack of c++11/14 features needed.
-
-
binary with PlatformToolset=v120_xp works
but binary with …=v140_xp does not.
Hmmm, I see the binaries are different in size
but I assume you just changed the toolset version
and the rest was kept the same, wasn’t it.I already searched the web, and there are some reports that there are problems
on windows xp when using VS2015 onwards but it looks like all of them were solved
by setting the compatibility flag aka toolset. Strange.Cheers
Claudia -
To be fully compatible with Windows XP, the following compiler’s option may need to be specified:
/Zc:threadSafeInit-This one relates to the “magic static” feature in C++ that depends on new TLS implementation available only from Windows Vista/7.
In case of Notepad++ plugin (i.e. a DLL file) the absence of this compiler’s option leads to crash (under Windows XP) while trying to use a static variable. In theory it should not have the same dramatic effect in an executable, but who knows? I think it’s worth trying to comile Notepad++ with this option specified. -
thank you very much for the hint.
If you wouldn’t mind to build one with this flag I would give it a try to see if it resolves the issue.
Cheers
Claudia
