How to disable new UI?

Dec 12, 2011 at 8:16 PM

Is any options to disable new terrible UI? It's very hard for eyes.

Coordinator
Dec 12, 2011 at 8:26 PM

Can you offer some more constructive feedback? What specifically about the new UI are you having a problem with?

Dec 14, 2011 at 3:22 PM
Edited Dec 14, 2011 at 3:34 PM

Perhaps a new color scheme and beautiful, but it is tiring eyes and I would like to turn it off.

I want to have the right to chooseAnd I think the color schemes is the last thing that is vitally important to this beautiful tool.

Can you make option to disable new skin?

Coordinator
Dec 14, 2011 at 3:26 PM

I'm not trying to defend the new UI - I'm trying to understand what it is you don't like about it so I can look at addressing it. Are you sure you can't get more specific than "terrible" and "tiring eyes"?

Dec 15, 2011 at 3:10 PM

I have no complaints about the speed of the new UI, but the color palette in my opinion is horrible.
The orange color makes much strain my eyes. I understand that you have invested a lot of time to implement a new UI, but I ask only option that will enable / disable it at will.

Coordinator
Dec 15, 2011 at 3:34 PM

Well then, if your only problem was with the color (and not the whole UI as you had implied), then you should be happy with the current build. The orange is gone.

Dec 16, 2011 at 6:28 PM

Thanks!

But i found another problem with new UI.

Non unicode build select wrong charset for display non-ascii data.

http://img851.imageshack.us/img851/1108/mfcmapi.jpg

http://img713.imageshack.us/img713/1073/mfcmapi2.jpg

September's build (without new UI) display these data without problem.

In unicode build all fine.

Coordinator
Dec 16, 2011 at 6:42 PM

Can you give me a hex string for some of this data which displays incorrectly so I can try to reproduce it here?

Dec 16, 2011 at 8:32 PM

For example PR_CONVERSATION_TOPIC

Hex:

5468652042617421202D20E7E0EFF0EEF120E8EDF4EEF0ECE0F6E8E8

In PropertyEditor i see correct display font.

In listview i see same text but with wrong codepage.

I have localized Outlook and all localized source displayed incorrectly.

Coordinator
Dec 16, 2011 at 8:44 PM

I'm not seeing any difference between the latest build and the September build. Could you give me screenshots of the September build and the new build looking at the same string (preferably the one you gave me the hex for) so I know what I'm looking for?

Dec 16, 2011 at 9:35 PM
Edited Dec 16, 2011 at 9:41 PM

Look from September build (non unicode)

http://img851.imageshack.us/img851/6990/sept1.jpg

http://img593.imageshack.us/img593/2329/sept2.jpg

Look from November build (non unicode)

http://img545.imageshack.us/img545/134/november1m.jpg

http://img543.imageshack.us/img543/2018/november2.jpg

Look from December build (non unicode)

http://img37.imageshack.us/img37/8594/december1.jpg

http://img859.imageshack.us/img859/6731/december2.jpg

As you see Left TreeView display localized source incorrect, starting from november build.

In right ListView column Value for PR_DISPLAY_NAME show text at wrong charset

But in PropertyEditor same text displaying correctly in all builds

Dec 16, 2011 at 10:06 PM

I think problem in that function

int CALLBACK EnumFontFamExProcW(
    _In_ LPLOGFONTW lplf,
    _In_ NEWTEXTMETRICEXW* /*lpntme*/,
    DWORD /*FontType*/,
    LPARAM lParam)
{
    // Use a 9 point font
    lplf->lfHeight = -MulDiv(9, GetDeviceCaps(::GetDC(NULL), LOGPIXELSY), 72);
    lplf->lfWidth = 0;
    *((HFONT *) lParam) = CreateFontIndirectW(lplf);
    return 0;
} // EnumFontFamExProcW


if i add line

 

lplf->lfCharSet = DEFAULT_CHARSET;

 

before CreateFontIndirectW() all text display in right charset

Coordinator
Dec 19, 2011 at 1:50 PM

Thanks for tracking that down. I was never able to get the strings to render as you did, but I think that's because I don't have the character sets you do. Your proposed change looks safe though, so I'll go ahead and implement it.