Version 6.50, Release Candidate #1 available

Started by Pelle, October 08, 2010, 03:50:54 PM

Previous topic - Next topic

AlexN

Quote from: Pelle on October 16, 2010, 04:12:22 PM
Quote from: AlexN on October 12, 2010, 07:56:32 PM
Is it a new feature or a bug?  ???

When I create a new source or open a short short file, the area for the line numbers and folding information is not coloured untilo the bottom of the window. It is only coloured as far as the source is.
It's a new feature. It makes it a little clearer where the file actually ends. It took me a few days to get used to it, but I like this better now...
Would it be possible to add a line or some else at the end of text :), so that the text background not only flow out. I would like more (but it is not really necessary).
best regards
Alex ;)

lamer

On Windows XP SP3 32 bit any attempt to reach any declaration file results in error.

I have reinstalled and rebuilt system definitions database several times with no success.

Also since version 5 if any optimization type is chosen in project options, compilation fails with fatal error: Internal error: get_rule(). Only if I choose no optimization the project is compiled normally. Unfortunately I cannot reproduce it on small project, but anyone can download the source http://downloads.sourceforge.net/pnotes/PNotesSource_6_5_110.zip and try to compile it with optimization.

frankie

#32
Pelle,
this is the shortes fragment from lamer Pnotes that generates the error.
And is also the only code lines that prevent compilation of module "controlpanel.c" in Pnotes project.
Same error occourse to some other modules, when I'll have time I'll try to isoled code fragments.
#include <windows.h>
#include <commctrl.h>


///** List View columns sorting ********************************************************/
typedef struct _LVSORT_TYPE {
int iSortName;
int iSortPriority;
int iSortCompleted;
int iSortProtected;
int iSortDate;
int iSortSchedule;
int iSortTags;
int iSortGroup;
int iSortBackOrigin;
int iSortBackDate;
}LVSORT_TYPE;


/** Module variables ********************************************************/
static LVSORT_TYPE m_LVSortBack = {LVS_SORTASCENDING, LVS_SORTASCENDING};


BOOL CALLBACK Tst (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{

if(m_LVSortBack.iSortName == LVS_SORTASCENDING)
m_LVSortBack.iSortName = LVS_SORTDESCENDING;
else
m_LVSortBack.iSortName = LVS_SORTASCENDING;
return FALSE;
}
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

frankie

lamer I compiled your program making the following modifications.
In module "controlpanel.c" I replaced all occourrence of code like that described in my previous post with the following construct:

m_LVSortBack.iSortName =  (m_LVSortBack.iSortName == LVS_SORTASCENDING ?
LVS_SORTDESCENDING : LVS_SORTASCENDING
);


In module "main.c" replace
if(m_NewDLLVersion)
m_nData.cbSize = sizeof(NOTIFYICONDATAW);
else
m_nData.cbSize = NOTIFYICONDATAW_V1_SIZE;


with:

m_nData.cbSize = m_NewDLLVersion ? sizeof(NOTIFYICONDATAW) : NOTIFYICONDATAW_V1_SIZE;


Then you should be able to compile with optimization.
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

lamer

frankie,
thank you very much!  ;D Actually this is the same code, so why does it behave different?
Any suggestion about definitions error? It is inconvenient to work without.
Ah, one more thing. The following fragment

case LVN_BEGINDRAG:{
        ...
RECT         rc;
LVITEMW lvi;
NMLISTVIEW *plv = (NMLISTVIEW *)lParam;
        ...
rc.left = LVIR_BOUNDS;
ListView_GetItemRect(m_hListMain, plv->iItem, &rc, LVIR_BOUNDS);
        ...

raises a warning:
warning #2130: Result of comparison is constant.
on line
ListView_GetItemRect(m_hListMain, plv->iItem, &rc, LVIR_BOUNDS);
This warning did not appear in previous versions. I don't see any comparison here.

TimoVJL

Quoteraises a warning:
warning #2130: Result of comparison is constant.
on line
ListView_GetItemRect(m_hListMain, plv->iItem, &rc, LVIR_BOUNDS);
This warning did not appear in previous versions. I don't see any comparison here.
In macro: ListView_GetItemRect()
#define ListView_GetItemRect(hwnd,i,prc,code)  (BOOL)SNDMSG((hwnd),LVM_GETITEMRECT,(WPARAM)(int)(i),((prc)?(((RECT*)(prc))->left = (code),(LPARAM)(RECT*)(prc)):(LPARAM)(RECT*)NULL))
May the source be with you

lamer

Quote from: timovjl on October 20, 2010, 10:55:18 PM
In macro: ListView_GetItemRect()
#define ListView_GetItemRect(hwnd,i,prc,code)  (BOOL)SNDMSG((hwnd),LVM_GETITEMRECT,(WPARAM)(int)(i),((prc)?(((RECT*)(prc))->left = (code),(LPARAM)(RECT*)(prc)):(LPARAM)(RECT*)NULL))

Thank you!

frankie

lamer,
yes the code is the same but the compiler cannot get a reduction rule for it. It is an internal issue of the compiler.
Only Pelle can answer, I immagine that the get_rule() is a routine to retrieve the code optimization strategy, that for this case is missing.
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

akee


Pelle

get_rule() is part of the general instruction selection, and it's just where the bug gets visible. It has nothing to do with the real problem here.

The problem boils down to m_LVSortBack being a struct, and the expression is using the first member (of type int). Usually all struct/array/etc members, except the first one, will be associated with an internally generated symbol which is <base + field-offset>, with the type being that of the field (and not the struct). The first member is special, since base + 0 is too silly to be generated. Unless I'm really careful, I might try to assign an int to struct (like in this case). The code generator (obviously) don't know how to handle this...

Finding a better solution may take a while...
/Pelle

Romashka

Quote from: Pelle on October 16, 2010, 04:25:56 PM
Quote from: Romashka on October 14, 2010, 08:52:21 AM
I see the button, and it's really useful.
However, it doesn't fix the problem. The font is too bold and contrasty because of antialiasing. Font lines are always at least 2 pixels wide. They were thinner in v6.0. Perhaps the old version didn't use anti-aliasing.
(I don't know if it has to do something with the added DPI awareness. I have 22" 16:10 1680x1050 monitor with default Windows DPI settings)
If it is possible to tune anti-aliasing of fonts in the Help, or optionally turn it off - that would be nice. If it's hard to do - nevermind.
Displaying the help file *should* be completely out of my control (it's done by the HTMLHelp engine). Since version 6.0 I really only flipped on a checkbox in the help generator program (for the new button), and recompiled. I can't see how that can affect anything. Also, I don't see any difference on my machine.

EDIT: of course, the font is choosen from a family of fonts which depends on the Windows version the help is displayed on. You may get "Segoe UI" which needs "ClearType" to be actived on a LCD screen (I have this enabled). Is this "off" on your computer?

I tuned Windows anti-aliasing settings and got much better fonts now.

CommonTater

Quote
I tuned Windows anti-aliasing settings and got much better fonts now.

If you're on Win-7, in the Control Panel->System->Advanced->Advanced tab there is a checkbox to turn font smoothing entirely off.  The screen is soooo much easier to read without it.... Also, since Help uses IE, if you go into your browser settings and select Arial as your bas font I think you'll find it's a lot easier to read than whatever the default is. 

Hope this helps...