Gammon Forum : MUSHclient : Development : Problem with text view

Log on

Gammon Forum

Entire forum

MUSHclient

Development

Problem with text view

Problem with text view

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

Pages: 1 2 3 4 5 6

Posted by

Twisol USA (2,257 posts)

bio

Date

Reply #15 on Sun 26 Sep 2010 10:28 PM (UTC)

Message

What the hey? Why does VS2010 Professional with MSDN cost $1000 in the US but $2000 in Australia? And why can I get a version without any MSDN stuff for $700?

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #16 on Sun 26 Sep 2010 10:33 PM (UTC)

Message

Checking a reseller (a local shop) gave me this:



Microsoft Visual Studio Pro 2010 Dvd

(Save $189.00 off RRP) 	$1,198.00 



Microsoft Visual Studio Pro 2010 w/MSDN

(Save $132.00 off RRP) 	$1,952.00

The figure of $189 off RRP exactly agrees with the figure of AU$1,387.00 quoted from the Microsoft site.

So yeah, slightly cheaper to drive to a shop and buy it (and saves download time) but still somewhat more than I want to pay for a bugfix.

And as for why? Well, we have long had the feeling of being ripped off for software over here.

Shipping charges, eh? Those software boxes are really heavy, it takes a lot of work to import them.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #17 on Sun 26 Sep 2010 10:36 PM (UTC)

Message

Nick Gammon said:
And as for why? Well, we have long had the feeling of being ripped off for software over here.

Shipping charges, eh? Those software boxes are really heavy, it takes a lot of work to import them.

I'm afraid that experience is universal. There's nothing fun about being able to guess a price in EUROs just by seeing the price in US DOLLARs simply by switching out the monetary sign.

Over here, they do not even (reasonably) have the 'shipping charges' excuse. :(

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #18 on Sun 26 Sep 2010 10:37 PM (UTC)

Message

Worstje said:

Nick, I dug into the sourcecode for the CEditView as VS2010s MFC has it, and I've put the parts I thought relevant up on Pastebin so you can try to figure out how to do a good fix.

What you have there is a variation on what I had (except for the test for the control version instead of the operating system version). If it passes the test, it would be behaviour B I had (where the find doesn't work) and if it fails the test I would get behaviour A (garbage).

But it shouldn't take heaps of code to fix - this only just started happening.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Twisol USA (2,257 posts)

bio

Date

Reply #19 on Sun 26 Sep 2010 10:41 PM (UTC)

Message

Nick Gammon said:
Shipping charges, eh? Those software boxes are really heavy, it takes a lot of work to import them.

I could have sworn there would have been a digital download option. :(

Let the world take note: This may have been the closest we will ever get to seeing Nick Gammon upgrade from VC++ 6.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #20 on Sun 26 Sep 2010 10:47 PM (UTC)

Amended on Sun 26 Sep 2010 10:50 PM (UTC) by Worstje

Message

I posted tons of links earlier in this thread, and I think one of them also explains why it is happening. In case I forgot the link with that information, I can explain the reason for as far I recall it.

For theming support, we need Common Controls v6. Common Controls v6 work, under the hood, as full unicode controls where the old ones do not. Which is why MSVC2010 does the check for the common controls version, as that one returns wchars. Otherwise, you get ordinary chars back, which very likely was the old codepath that has zero issues.

Problem is that your version has wchars casted as chars, meaning they kinda look like chinese characters were you to use the right font.

So from what I saw from your commit, you totally cut out the non-unicode (v5) bits. You need to keep both in there I am pretty sure. It's just the bwin95 check that is bonkers for as far I can tell without any upclose experience with it.

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #21 on Sun 26 Sep 2010 11:02 PM (UTC)

Message

Twisol said:

I could have sworn there would have been a digital download option. :(

Yes, there is a digital download option. That's AU$1,387.00.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Twisol USA (2,257 posts)

bio

Date

Reply #22 on Sun 26 Sep 2010 11:04 PM (UTC)

Amended on Sun 26 Sep 2010 11:13 PM (UTC) by Twisol

Message

Australia: Where killer spiders are household pests, and software is morbidly overpriced.

(Okay, I'm done. *cough*)

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #23 on Sun 26 Sep 2010 11:08 PM (UTC)

Message

Worstje said:

I posted tons of links earlier in this thread, and I think one of them also explains why it is happening. In case I forgot the link with that information, I can explain the reason for as far I recall it.

For theming support, we need Common Controls v6. Common Controls v6 work, under the hood, as full unicode controls where the old ones do not. Which is why MSVC2010 does the check for the common controls version, as that one returns wchars.



C:\source\mushclient\TextView.cpp(1783) : error C2065: '_AfxGetComCtlVersion' : undeclared identifier

C:\source\mushclient\TextView.cpp(1783) : error C2065: 'VERSION_6' : undeclared identifier

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by Worstje Netherlands (899 posts) bio

Date

Reply #24 on Sun 26 Sep 2010 11:16 PM (UTC)

Amended on Sun 26 Sep 2010 11:22 PM (UTC) by Worstje

Message

afximpl.h defines those things, although I'm not exactly sure how yet.

// for determining version of COMCTL32.DLL
#define VERSION_WIN4    MAKELONG(0, 4)
#define VERSION_IE3             MAKELONG(70, 4)
#define VERSION_IE4             MAKELONG(71, 4)
#define VERSION_IE401   MAKELONG(72, 4)
#define VERSION_6		MAKELONG(0, 6)
extern int _afxComCtlVersion;
DWORD AFXAPI _AfxGetComCtlVersion();

According to http://www.codeproject.com/KB/shell/detectie.aspx?msg=81402, you can simply do:

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

 
if (_AfxGetComCtlVersion() >= VERSION_6)
{
    //...
}

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #25 on Mon 27 Sep 2010 12:08 AM (UTC)

Message

Odd. That seemed to work. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #26 on Mon 27 Sep 2010 12:12 AM (UTC)

Message

So, were you able to completely fix your issues with the garbled text now in both debug and release builds?

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #27 on Mon 27 Sep 2010 12:18 AM (UTC)

Message

Yes, I would tentatively say it is fixed. Thanks for your assistance. :-)

I have pushed that change, and also a rather large set of file changes which attempt to help with the memory leak detection.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by Worstje Netherlands (899 posts) bio

Date

Reply #28 on Mon 27 Sep 2010 12:42 AM (UTC)

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

Message

Any chance your...

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

... could lose the relative paths? It just broke my build as I obviously do not have the file there. Then again... I am not sure how to proper reference that file. Gonna figure that out a bit later, but for now at least I posted here.

Found it. The following makes it work for me.

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

I am not sure about 2005 and such, but can you add an #if for later compiler versions (or maybe later a _MFC_VER would be more appropriate) so that the file is included from the proper place depending on what MFC version we're using?

Edit (yet another one):

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.

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #29 on Mon 27 Sep 2010 01:05 AM (UTC)

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

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.

189,078 views.

This is page 2, subject is 6 pages long: 1 2 3 4 5 6

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

Go to topic: Search the forum

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.