Plugin built with VS 2013 Express vs. Plugin built with VS 2013 Community

Claudia Frank

Oh, didn’t saw that it was different repository.
Downloaded pnedev’s version, compiled and run -> same result.

Can you try the little test I suggested?

Cheers
Claudia

Yaron

Hello Claudia,

Thanks again. I highly appreciate it.

I get the same wrong results with your test.

You have the WinDDK 7.6.1 installed, correct?

Well, I’m baffled. :)

Best regards.

Claudia Frank

Hello Yaron,

when we compare the two screenshots (old/correct and new/wrong) we see that
from compare plugins point of view it isn’t a problem. You might asking - what?

My current idea is the following:

The two additonal lines in prefs.js should be marked as empty lines in prefsBackup.js
by adding two eols(\r\n) and change background color to grey.

Well the background color has been set to grey for two lines, just one eol disappeared.
And the next line user_pref(“extensions.bootstrappedAddons”… got recognized by the compare
plugin that it exists in both files.

So could it be that you have a plugin/configuration that automatically compresses two (maybe more) empty lines
into one? And this conflicts now with compare plugin?

Cheers
Claudia

Yaron

Hello Claudia,

That’s a clever idea.

I’m afraid I haven’t made myself clear enough.

The same source code built by someone else (and uploaded to the Compare repo) works as expected on my machine with the exact same settings.
That DLL was built with VS 2013 Community and hence my initial idea of some difference between VS Express and VS Community.

After you have kindly built the code with VS Express and got correct results that explanation seems irrelevant.

A wrong setting in my VS Express?
And a long shot: is it possible that it only works properly when built on Windows 64-bit?

Thank you very much. I do appreciate your help.

** I won’t be by a PC until Wednesday or Thursday.

Best regards.

Claudia Frank

Hello Yaron,

A wrong setting in my VS Express?

You are using the same repository that I do, all settings should be the same as they are stored in
solution and project files.

And a long shot: is it possible that it only works properly when built on Windows 64-bit?

32bit/64bit hmmm, could be a culprit.

Which OS do you use?
Which regional settings?
Can you upload the faulty compare dll?

Cheers
Claudia

Yaron

Hello Claudia,

You are using the same repository that I do, all settings should be the same as they are stored in
solution and project files.

I meant some wrong/corrupted setting in general.
Apropos: when I open the Compare.sln file, I need to change the default Debug setting to Release. Is that normal?

My OS is Windows 7 32-bit.
Regional settings: English/Hebrew.
ComparePlugin.dll (my build).

Thank you very much. I appreciate your kindness.

Best regards.

Claudia Frank

Hello Yaron,

I can confirm the reported behavior with your dll, even on my Win7 64bit.

Regarding the Debug/Release what do you mean you NEED TO change it?
Is something not working if you build the dll with Debug profile?
With Debug profile the created dll is much bigger as it has additional debug information.
Once you are fine with your coding you would change to Release profile and
create a lighter (smaller) version of the dll.

So the question is, what happens on your system when compiling the system.

As said, the project specific settings are stored in sln and project files.
The other settings shouldn’t harm and actually I’m not aware of a setting
which could lead into the situation that such setting would delete a \r\n char.

When you compile the source do you get any error or warning message?
How did/do you get the source, by downloading the current zip or via
git tools like git and tortoisegit? If using git tools do you pull from master branch?
If using tools, what does commit show if you right click on the directory of the repository?

In the meantime I will try to see what your dll can tell me.

Cheers
Claudia

Yaron

Hello Claudia,

Thank you so much. Highly appreciated.

My long shot was a difference between building the DLL on 32 or 64.

Debug/Release: I meant to ask if the default setting on opening the file was Debug.

I don’t get any errors or warnings.

I download the current zip (master branch).
If I hover over an older commit’s <> button (Browse the repository at this point in the history), download the up-to-then source code and build it - I get correct results.

Best regards.

Claudia Frank

Hello Yaron

My long shot was a difference between building the DLL on 32 or 64.

I don’t think so, but bugs could be anywhere.

Debug/Release: I meant to ask if the default setting on opening the file was Debug.

Yes, as this it the main profile a developer works with.

I don’t get any errors or warnings.
I download the current zip (master branch).
If I hover over an older commit’s <> button (Browse the repository at this point in the history), download the up-to-then source code and >build it - I get correct results.

Which commit did you use? What about if you use the latest one?

Cheers
Claudia

Yaron

Hello Claudia,

Thanks again. :)

Using the latest commit - wrong results.

A few minuets ago I downloaded the source up to this commit and got correct results.

I think the problem started here. I can test again and verify it.

Best regards.

Claudia Frank

Yaron, could you post your compare.ini?

Cheers
Claudia

Yaron

Hello Claudia,

Compare.ini.

Thank you very much.

BR

Yaron

Hello again,

The problem starts in this commit.

Thank you.

BR

Claudia Frank

This is were I currently investigate, to be more precise I assume the issue in addBlankSection.

Cheers
Claudia

Yaron

You’re amazing.

On one hand I think that it’s too much, but on the other hand I don’t want you to stop. :)

I was about to start investigating it myself; I was overwhelmed by the scale of the unfamiliar code.

Thank you very much!

BR

Claudia Frank

It might be that this was a hasty reaction as it could be that the function already got the wrong value.
What I can say so far is that the inserttext from addBlankSection

::SendMessage(window, SCI_INSERTTEXT, posAdd, (LPARAM)buff.data());

only gets one '\r\n”

{'text': '\r\n',            'modificationType': 0x11,      'linesAdded': 1, 'length': 2, 'position': 3, 'line': 0 }

whereas my dll gets three

{'text': '\r\n\r\n\r\n',    'modificationType': 0x11,      'linesAdded': 3, 'length': 6, 'position': 3, 'line': 0 }

Test was done with two files, one having

1
5

whereas the other has

It is most likely that I need your help to find out what the problem is, meaning
you need to do some debugging as well. But not for today, I need to have a rest.
Maybe we can go on tomorrow?

Cheers
Claudia

Yaron

Good morning Claudia,

I hope you’re reading these lines after having a good and refreshing rest.

I find it difficult to enlarge the variety of my thanks expressions.
So, many thanks again. :)

I’ve never used the Debugger.
Bear with me.

Have a great day.

Claudia Frank

Hello Yaron,

The problem is generated by a compiler bug. It tries to optimize a little bit too much. ;-)

Either disable optimization, by right clicking on compare in project explorer,
properties -> C/C++ -> all options -> Optimization and change its value

or the preferred way

update your visual studio 2013 to latest version. ;-)

Cheers
Claudia

Yaron

Hello Claudia,

You never cease to amaze me.
I take my hat off. Oracle Claudia!

Thank you so much. I’m truly grateful.

Could you please enlighten me and explain briefly how you got it?
I hope it’s not a trade secret. :)

Best regards.

Claudia Frank

Hello Yaron,

no, it isn’t a trade secret ;-) - but it wasn’t really a clever job, it was just an eliminating process and LUCK.

I only tell you the steps which lead to the finding not the many wasted miserable steps I’ve done before. ;-)

After I didn’t find any obvious issues which could explain reported behavior I thought about the differences of your
and mine environment. After that I setup an windows 7 32 bit with visual studio 2013. Downloaded source and compiled it.
Tested it and it worked. Even more confused as I expected it to fail. Thought about it again and started comparing yours and mine.
Same W7, same VS2013, same source -> different results.
Same W7 (?) -> didn’t install all updates -> didn’t use Hebrew = keep in mind
VS2013 -> same
source-> same, you did even test it with different npp version as I read.
So it must be W7 -> why??? Did a search on the internet about reporting problem with VS2013 and non-english language.
Results, but nothing pointing to such an issue.
Then I did a search about problems with visual studio and having different language. And while scanning the result
I saw one who had an issue installing an update - that’s where I started thinking about different version.
I had VS2013 update 4 already so I gave it a chance and -> compiled the source and tested it -> problem was the same.

You see, no rocket science.

Cheers
Claudia