[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Development
. . -> [Subject]  Problem with text view
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Problem with text view

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Pages: 1  2  3 4  5  6  

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #30 on Mon 27 Sep 2010 01:09 AM (UTC)

Amended on Mon 27 Sep 2010 01:10 AM (UTC) by Twisol

Message
<../src/mfc/afximpl.h> works under VS2005 for me.

Worstje said:
Talking with Twisol on AIM, and I realized it might be better not to fix the include to be right, but rather to make sure your fixes for the blocks only affect the VC++6 and its MFC version. After all, our versions have the bug fixed, so your fixing MFC6 might actually break stuff for us because we are messing around with the internals.

That sounds like a much better plan in my opinion. Only fix what's broken, right?

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #31 on Mon 27 Sep 2010 01:13 AM (UTC)

Amended on Mon 27 Sep 2010 01:14 AM (UTC) by Worstje

Message
Nick Gammon said:

Well

#include <../src/afximpl.h>

and

#include <../src/mfc/afximpl.h>

aren't going to both work are they?

Do you want to #define all that extra stuff away for you, is that what you are saying? Maybe test first and see.


That's why I was suggesting you add:
#if _MSC_VER >= 1400    // doesn't work with Visual Studio 6
#include <../src/mfc/afximpl.h>
#else
#include <../src/afximpl.h>
#end


That way the include is correct for us. Although avoiding including it for non-VC++6, and #if'ing your fixes for the bug for your VC++6 version in specific seems like an even better (cleaner?) idea having thought about it in more detail.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #32 on Mon 27 Sep 2010 01:19 AM (UTC)
Message
Twisol said:

That sounds like a much better plan in my opinion. Only fix what's broken, right?


This is what I hate about all this adapting to different things (the themes are another case in point). The whole thing is turning into a delicate flower, where there are tests for exact versions of libraries, exact versions of the compiler, conditionally including stuff here but not there, and so on.

I don't want to conditionally include source, more than absolutely necessary, depending on the compiler version. Testing a runtime library, well if it has to be done, it has to be done.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #33 on Mon 27 Sep 2010 01:46 AM (UTC)
Message
Well, I am sorry to inform you, but requirements change over the years. I can't help the fact Windows gets new features, and people like to see those features used while at the very same time, you insist on keeping compatibility with Windows 95 and the likes.

I don't like the fact that, to fix a bug affecting YOUR version of MFC only, ALL versions of MFC get a fix applied that might well conflict with their inner workings which are NOT garantueed to be compatible with OLDER versions - only the interfaces are garantueed to be compatible. If your fix ends up requiring a header that is considered 'innards', don't make us require it either - this situation shows it is obviously not garantueed to exist for us in the same location.

If this post comes over as a bit hostile, I apologize. I know the MUSHclient source code ain't the most beautiful thing ever, and I avoid bringing that and the word 'refactor' up. I accept that I'll work with what we have. However, I do refuse to accept that because it is already a relative mess that we do not have to think about the best approaches to a situation such as this one.

There is no way to avoid conditionally including header files. If you want to minimize that, it is best to refactor the fixes to only affect your compiler version.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #34 on Mon 27 Sep 2010 02:54 AM (UTC)

Amended on Mon 27 Sep 2010 02:55 AM (UTC) by Nick Gammon

Message
Right. Finally I have worked out what has been happening over the last couple of days. Fully two days, I would way, working out why, suddenly, with no code changes I could account for to cause it, the notepad window suddenly showed garbage.

Just to recap:


  • The notepad window has worked fine for years.

  • I recently made various changes to other parts of the code - some of which were just moving code around into different files.

  • Some improvements were also made, but basically the CTextView was not touched at all.

  • Suddenly, the notepad just showed garbage.

  • Reverting back to previous commits didn't fix the problem.

  • It seemed to be just something in version 4.62, but no code change seemed to be possibly responsible.

  • With the assistance of Worstje, and adding a substantial amount of extra code the problem went away.

  • There were then complaints that this should be conditionally added because recent compilers "weren't broken" like mine was.

  • There have been hints that perhaps I should spend $1000+ to get a "better" compiler.


But none of this explains why. Why did it suddenly start happening? I deleted all temporary files, did a rebuild all, everything I could think of. Then there was a small clue, doing a debug start up:


Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\version.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\winmm.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\shlwapi.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\comdlg32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll', 
   no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\shell32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\winspool.drv', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\oledlg.dll', no matching symbolic information found.


What the heck is C:\WINDOWS\WinSxS? A quick Google reveals it is part of Microsoft's "compatibility" system. But I didn't remember seeing that before.

Aha! There was one change recently - but not to the source, which is why reverting the source didn't affect anything. Here it is ...

Worstje said:

I created a theming branch on github, and have already fixed the bug regarding the notorious "tip of the day" dialog.

...

May I request testing and, assuming there are no issues, to have support for visual styles turned on by default?


The problem is caused by having the file MUSHclient.exe.manifest in the MUSHclient directory. No wonder reverting the source didn't fix it, because that file wasn't reverted (ie. deleted).

To be fair to Worstje he didn't expect this to happen. Neither did I. And had the problem surfaced the moment after putting the manifest file there I would have twigged. But it was like hours later, or the next day, after even more source changes, that I thought to open the internal notepad. One of the reasons for that is, that I use Crimson Editor most of the time, and when I hit "edit" to edit a plugin, it just goes to Crimson Editor.

What the new themes did is bring in a new comctl32.dll which handled the edit controls differently. Pretty subtle huh? Pretty annoying too.

It's annoying because, whilst I sympathize with the idea of a more modern look and feel, making a change that basically just gave you rounded buttons and a few shadows here and there, has wasted two days of my time.

And then the solution (the interim solution we had) isn't something I feel totally comfortable with. What if, for example, thousands of existing users who don't happen to have that control now have the client fail? What if some people don't have UxTheme.dll?

You have already complained here that you don't want to make changes "to fix a bug affecting YOUR version of MFC only". Well, how can you say with confidence that it will work whatever we do?

Certainly no-one predicated that adding in the manifest file would cause corruption in the notepad window. So I wonder what else unexpected will happen?

If Microsoft supported their developers (like Apple do, and Linux) by giving away the development tools, then I could accept that I should have the most modern tools. But when it is a thousand dollars every three or four years (after all, there is VS2005, VS2008, VS2010, then I feel like I am just giving them money for basically bug fixes. Big money. Especially when I get practically no income from MUSHclient.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #35 on Mon 27 Sep 2010 03:07 AM (UTC)
Message
Now that I know what to look for doing a Google for "ceditview manifest" reveals quite a few hits. A bit of griping too, because this is obviously not a new problem.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #36 on Mon 27 Sep 2010 03:12 AM (UTC)
Message
This is my manifest file (as suggested by someone a while back):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
   xmlns="urn:schemas-microsoft-com:asm.v1"
   manifestVersion="1.0">
<assemblyIdentity
    processorArchitecture="x86"
    version="5.1.0.0"
    type="win32"
    name="MUSHclient.exe"/>
    <description>MUSHclient</description>
    <dependency>
    <dependentAssembly>
    <assemblyIdentity
         type="win32"
         name="Microsoft.Windows.Common-Controls"
         version="6.0.0.0"
         publicKeyToken="6595b64144ccf1df"
         language="*"
         processorArchitecture="x86"/>
    </dependentAssembly>
    </dependency>
</assembly>


There seems to be a hint somewhere that maybe v5 of the common controls will not have this problem, if you happen to know the manifest file for that.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #37 on Mon 27 Sep 2010 03:18 AM (UTC)

Amended on Mon 27 Sep 2010 03:23 AM (UTC) by Twisol

Message
Nick Gammon said:
*There were then complaints that this should be conditionally added because recent compilers "weren't broken" like mine was.

Suggestions. Also this has nothing to do with the compiler, we've shown that it's actually MFC 6 - a library that's bundled with the VC6 IDE - that has the issue.

Nick Gammon said:
*There have been hints that perhaps I should spend $1000+ to get a "better" compiler.

Suggestions. I'm not about to get into the business of forcing people to spend money they don't want to spend. What I was doing is trying to determine why it costs so much, and whether there was a better deal. Also, note that it's only $200 to upgrade from VS2005/2008 to VS2010. VC6, on the other hand, is officially unsupported.

Visual Studio is not just the compiler, but also the visual environment, included libraries (MFC being the obvious one), assorted utilities (the resource editor comes to mind), and an (unwanted) MSDN subscription. If it were just a compiler I think we'd have far fewer issues... C++ doesn't change that quickly, as shown by how successful we've been in working on the same code in both VC6 and VS2010. Besides, the Express editions come with the same compiler. What are they missing? Other bundles, like MFC.

Sorry, Nick, it's just been getting on my nerves that you refer to Visual Studio as a "compiler" and compare it to g++.

Nick Gammon said:
What the new themes did is bring in a new comctl32.dll which handled the edit controls differently. Pretty subtle huh? Pretty annoying too.

I toyed with the manifest before any of this came to light, and right inside the file it shows a dependency. It's not very subtle unless you forget it's there (which I agree can be a problem).

Nick Gammon said:
What if some people don't have UxTheme.dll?

Worstje and I talked about this, and if you look at his code, I believe it will fail gracefully. That's why it doesn't add the uxtheme library as a hard dependency.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Reply #38 on Mon 27 Sep 2010 03:29 AM (UTC)
Message
Quote:
What the heck is C:\WINDOWS\WinSxS?


It's the Windows Side by Side directory, and how the .Net framework tries to avoid DLL hell...
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #39 on Mon 27 Sep 2010 03:31 AM (UTC)

Amended on Mon 27 Sep 2010 03:33 AM (UTC) by Worstje

Message
Nick, there is a lot of stuff in your last post, and a lot of (pent up) frustration as well. Also, I need to point out... the entire 'why' you wrote down just now is something I already explained once around four hours ago. Not in as much detail as you have, I admit, but if you spent the last four hours figuring out that I think it is sad my posts ended up lost in the discussion concerning the monetary cost of a VS2010 purchase.

The moment I made the change I made an explicit comment in the source regarding a CEditview bug of which I then did not find the details. I checked all source code and only found a few references, since the rest was in a derived class (CTextView), so I wrote down that I thought it not to be an issue at present. Never the less, I made sure to document it.

Quote:
You have already complained here that you don't want to make changes "to fix a bug affecting YOUR version of MFC only". Well, how can you say with confidence that it will work whatever we do?

Certainly no-one predicated that adding in the manifest file would cause corruption in the notepad window. So I wonder what else unexpected will happen?


I will answer your two questions in reversed order. I am going to be ruthless, and say I did predict it. I will quote the comment I mentioned above:

/* Manifest instructions for the linker.
 * Originally there is an '#IFDEF _UNICODE' statement around these pragmas, but we don't compile as _UNICODE.
 * Research shows this #IFDEF seems to exist by default due to a bug in CEditView in MBCS mode, but I do not
 * believe this bug can affect us at present as it involves 'loading from files'. Testing thus far seems to
 * confirm there is no different behaviour in/around the command window with this enabled. -JW
 */


In the beginning of this thread, you noticed the problem with the garbled notepad window. You even found that comment. If I were to look back on the appropriate forum topic, I am pretty sure I would also find a request of myself asking you and Twisol to test it to see if it didn't cause trouble. My MFC version does not have this bug, and I could never have caught it myself.

Second (first?) question. Can I be confident that it will work no matter what we do? Hell no. We are developing for a modern-day environment using a 10-year old compiler as our primary code-cruncher, around 10-year old bugs with no support from Microsoft. But _within_ those requirements, I am damn confident. Why?

1. One of the articles linked elsewhere in this thread shows three different bugs in the MFC Visual C++ 6 uses (called 'bugged MFC' from now on). One of them describes this particular bug in enough detail to understand the issue.
2. Using the latter and some digging into VS2010 source files, we managed to engineer a fix that stops the bugged MFC from messing up the output window.
3. I made sure to make all calls to uxtheme.dll dynamic calls, so they do not affect backward compatibility. This took considerable effort which I commented extensively - which your post just now betrays not even skimming over.

The only confidence I do _not_ have is that it will keep working on newer compilers, since we are working around a bug for the bugged MFC on all MFCs, even those with the bug fixed. At some point, if not properly specialized to focus on the bugged MFC only, it will cause hard to track bugs for people compiling MUSHclient under that environment.

This post is a bit late since I took my time writing it, but the implications inbetween the lines are really starting to annoy me. I did expect a lot of this, be it in less detail, and I feel as if I am being blamed for checking in changes without testing. I made every single effort I could, adding comments, asking for code reviews, posting posts on the forum, and still it ends up as 'I wasted 2 days tracing a mystery bug'.

Nick, I love you to death, but you confuse me like no other at the same time. You want to know what things do before checking them in, yet all my comments in the source and on the forums here seem to fall upon deaf ears. I do not have you on AIM, so the slow/indirect communication is likely a big part of our communication troubles, but this is not conducive for anyone: you get frustrated with us, and we get frustrated with you. Old compilers, new compilers, in the end they are a detail that becomes a focus due to communication failing us.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #40 on Mon 27 Sep 2010 03:59 AM (UTC)
Message
Well to give you credit - and I suppose I overlooked this a bit - your comments about the CEditView were indeed adjacent to the stuff about the manifest.

I suppose I just didn't twig that the mere inclusion of the manifest file - and not changes to the source per se - caused my problems.

And to be fair to Twisol:

Twisol said:

That's odd. ... Maybe it has to do with the theming that Worstje enabled? ...

Try using `git bisect` to determine which precise commit did it?


I focused more on the "precise commit" issue rather than the "theming that Worstje enabled". With the benefit of hindsight, I followed the wrong path.

Oh well, when we have all calmed down a bit (particularly me, eh?) we will have a better end result. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #41 on Mon 27 Sep 2010 04:05 AM (UTC)
Message
Nick, do you have AIM or some other instant messenger? I think in the future we might be able to save ourselves a lot of time with a bit directer line of communication.

(I have no intention of taking discussions away from here - merely to improve communications when forum posts are a bit too clumsy for communication.)
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #42 on Mon 27 Sep 2010 04:08 AM (UTC)
Message
Worstje said:

... yet all my comments in the source and on the forums here seem to fall upon deaf ears....


Well not totally, and we got a result, working together.

You are probably familiar with the concept of "what I heard is not what you said". Sometimes we hear what we expect to hear, and see what we expect to see.

On a more humorous note, check out this:

http://www.youtube.com/watch?v=vBPG_OBgTWg

In this video the fellow experiments by swapping people in mid-conversation and seeing if the subject notices. This has been done a few times, and in most cases they don't. They already have made up their minds about what they are seeing and even blatant evidence to the contrary doesn't appear to shift them.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #43 on Mon 27 Sep 2010 04:18 AM (UTC)
Message
Nick Gammon said:

On a more humorous note, check out this:

http://www.youtube.com/watch?v=vBPG_OBgTWg

In this video the fellow experiments by swapping people in mid-conversation and seeing if the subject notices. This has been done a few times, and in most cases they don't. They already have made up their minds about what they are seeing and even blatant evidence to the contrary doesn't appear to shift them.


That's some pretty awesome stuff. Now I am tempted to pull some practical jokes like this coming april. xD

(Any chance you can answer my question in my previous post? I think you missed it.)
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #44 on Mon 27 Sep 2010 04:20 AM (UTC)
Message
Worstje said:

Nick, do you have AIM or some other instant messenger?


I don't have AIM. Would logging into some random MUD and chatting amount to the same thing (eg. Aardwolf)?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


55,207 views.

This is page 3, subject is 6 pages long:  [Previous page]  1  2  3 4  5  6  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]