I installed the new version of Lazarus(as I always do) and tested my program that counts Kenorows but,
that the new FreePascal/Lazarus been 5 sec slower5 seconds seems to be a lot, but if you relate it to the total running time of the procedure of more than 80 seconds that's nothing. Are these number reproducible? I'd expect such a deviation for the same program due to background processes or caching.
Another observation is that the dialog "Installing Lazarus", in spanish, doesn't have a correct transalation for the accented vocals.Can you check the source file in tools\install\win\lazarus.es.isl ?
It installs OK and creates two access in the Start Menú. But it doesn't create another link on the Desktop. Is it OK?
I'm installing the 1.2RC1, as a second instalation, and I still think that the Dialog "Select configuration folder" should have a default path. It is some confused.
Can you check the source file in tools\install\win\lazarus.es.isl ?
That is because according to the Rules of most OS (incl Windows) config goes into a special folder in the users home dir.
So the primary goes into %appcondir%/lazarus (or0 maybe app_local_conf)
I think we don't need to follow the rules for a second installing. It could be the same path that we choose for the Second installation. It would be simpler for the user.
About the Spanish: I did sent you a PM, maybe it is utf8 vs ansi.
I think we don't need to follow the rules for a second installing. It could be the same path that we choose for the Second installation. It would be simpler for the user.
The installation may run as admin, and the path may not be writeable to the user. What then?
Is there anywhere a precompiled version for Mac OS X PPC available or have I to build it myself?
The installation may run as admin, and the path may not be writeable to the user. What then?I just suggested to use the same Path used for installation. If you can install there, you can write. Or probably, I'm not understanding the problem.
P.S.: looks like it also crashes when I click "new unit" button on the toolbar
I've installed again as a secondary installation on spanish.
But now, every time I open a project, it shows me a Windows with the message: "Error: system.ppu no found. Verify your fpc.cfg.". Then run OK.
--primary-config-path=C:\lazarus2
Carbon is 32-bit only, so any attempt to compile it for 64-bit is expected to fail.
Cocoa, in its implementation (at least originally) were using a lot of Carbon functions. In this particular sample - theme drawing.
That can be definitely removed (as the API is or intent to be deprecated by Apple), however the widgetset itself will have less functionality.
OT but when I install sqlite3laz.lpk from sqlite component Lararus will not start. Ther is error about sqlite3.dll
So until you get sqlite3.dll you not run Lazarus. Maybe sqlite3.dll should be added to installer ? or Lazarus should after all run (to be able to uninstall sqlite package).No no external dlls should be installed with lazarus this opens the expectation door that the library is somehow maintained-supported by the team.
@kamischi
On Mac currently all GUI development is limited to 32 bit
This is what I got from one my colleagues:QuoteCarbon is 32-bit only, so any attempt to compile it for 64-bit is expected to fail.
Cocoa, in its implementation (at least originally) were using a lot of Carbon functions. In this particular sample - theme drawing.
That can be definitely removed (as the API is or intent to be deprecated by Apple), however the widgetset itself will have less functionality.
I've installed again as a secondary installation on spanish.
But now, every time I open a project, it shows me a Windows with the message: "Error: system.ppu no found. Verify your fpc.cfg.". Then run OK.
--primary-config-path=C:\lazarus2\conf
- Save it done.I have tested it under Mac OSX 10.8.2 and it freezes on start. I see the splash and then it enters the freeze, I am trying to get a dump, but was not successful so far.
about sqlite: best would be if the dll was not hard-linked, but loaded dynamical at runtime.Note: you don't even have to install sqlite3laz.lpk to get sqlite support in Lazarus. Seems like a lot of people make the mistake of thinking that it is needed... and I'm wondering how we can make it clearer it's not.
Then the IDE (and any app) would still run, but could give an error if trying to use sqlite.
Not sure if the relevant developers will read this at the forum. Better to be discussed on the mail list.
Or add a feature request on mantis, or a patch ;)
Probably related to http://bugs.freepascal.org/view.php?id=25322
The patch indicates one location where this may happen, however there are more.
type
TSomething = class
procedure Fudge: Integer
it shows error message not in the Compiler Messages window, but in a separate small window like it is application-level fatal exception, not syntax errorShould I report this as a feature request on the bugtracker? I believe there there is no such request already there...A general help button has been implemented in Laz trunk (though it loads lhelp, it doesn't show contents on my current dev lazarus, might be that there is some more work needed - probably due to partly patched bug 24743: LHelp flickers loading files and does not close when Lazarus closes). Loading all help files in the chm help directory when lhelp starts has been implemented in at least trunk.
Hmm, so it seems no further bug reports are needed, the feature is on the way?
I'm quite satisfied with how LHelp works the way I set it up in the custom tools menu (besides not closing with Lazarus, not a big issue for me). All the relevant help files are included and present in the TOC, and I see no flickering or any other problem with the LHelp itself. I wouldn't mind if it stays this way indefinitely (it only required that minor effort to set up), but moving such feature to the help menu would definitely help (confused) new users. There are enough complaints about lack of documentation already ;)
Options changed, recompiling clean with -B
Hint: Start of reading config file /etc/fpc.cfg
Hint: End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 2.6.2-5 [2013/07/25] for x86_64
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling /home/mariuz/tmp/project1.lpr
Compiling unit1.pas
Compiling resource lib/x86_64-linux/project1.or
Linking /home/mariuz/tmp/project1
/usr/bin/ld.bfd.real: warning: link.res contains output sections; did you forget -T?
/usr/bin/ld.bfd.real: skipping incompatible /usr/lib/i386-linux-gnu/crti.o when searching for /usr/lib/i386-linux-gnu/crti.o
/usr/bin/ld.bfd.real: cannot find /usr/lib/i386-linux-gnu/crti.o
project1.lpr(20,1) Error: Error while linking
/usr/bin/ld.bfd.real: warning: link.res contains output sections; did you forget -T?
/usr/bin/ld.bfd.real: skipping incompatible /usr/lib/i386-linux-gnu/crti.o when searching for /usr/lib/i386-linux-gnu/crti.o
/usr/bin/ld.bfd.real: cannot find /usr/lib/i386-linux-gnu/crti.o
project1.lpr(20,1) Error: Error while linking
project1.lpr(20,1) Fatal: There were 1 errors compiling module, stopping
When I close Form2 first, the onClose event fires normally
When I close the application by closing Form1 first, the onCLose event of Form2 does not fire.
The onDestroy does fire though, so it's not a disaster.
Is this a bug, or a feature?
Hi, in lazarus 1.2RC1, has the same bug: http://forum.lazarus.freepascal.org/index.php?topic=22530.0 (http://forum.lazarus.freepascal.org/index.php?topic=22530.0)
r43364 Debugger: prevent messing up the environment on windows, due to gdb bug (gdb not setting debuggee environment) / introduced in rev 42419
The fix has already been merged to RC2Thanks
The docking package causes a lot of issues. I was using it but went back to the floating set up instead as it was just less hassle.
I do prefer a fully docked IDE, but f12 simply does not work correctly with docking enabled.
Hi,
I encounter a problem.
Platform: Windows XP SP3, IDE version: Lazarus IDE v1.12RC1
In unit file, The single quote mark by the right side is not displayed when using plus sign to connect strings, which contains only one Chinese punctuation ‘、’, when keeping cursor away from the string. It will be display correctly When putting cursor inside, or against the left side of, or against the right side of the string.
So, I change the environment as below.
// take several samples
ETO := False;
change the value to "True"program project1;
type
{ TSearcher }
TSearcher = class
public type TResult = record
Name: string;
end;
public class function Search: TResult;
end;
{ TSearcher }
class function TSearcher.Search: TResult;
begin
result.{press Ctrl+Space here: won't work}
end;
begin
end.
The release page for 1.2.0 doesn't list any change that could affect what I'm doing, but you know, maybe the page got outdated (after all, it says nothing about SynEdit).It is usually well maintained, but that said we are all human, and oversight is possible.
today was a glorious day I enabled the win7 themes after working almost 2 years with out them in any case here is a screenshot of the component bar take a look on the menus. Is it only me that sees that or you guys have the themes disabled too?It seems to me there is one pixel missing.
function MenuItemSize(AMenuItem: TMenuItem; AHDC: HDC): TSize;
..
if AMenuItem.IsInMenuBar then
Result := VistaBarMenuItemSize(AMenuItem, AHDC)
........
function VistaBarMenuItemSize(AMenuItem: TMenuItem; ADC: HDC): TSize;
..
Metrics := GetVistaBarMenuMetrics(AMenuItem, ADC);
..
Result.cx := Result.cx + Metrics.TextSize.cx + IconSize.x;
........
function GetVistaBarMenuMetrics(const AMenuItem: TMenuItem; DC: HDC): TVistaBarMenuMetrics;
..
Result.TextSize.cx := TextRect.Right - TextRect.Left;//<--- missing one pixel?
Result.TextSize.cx := TextRect.Right - TextRect.Left + 1;//<--- correction
TextWidth := TextRect.Right - TextRect.Left + 1;
//20 := 19 - 0 + 1;
[snip...]
You should have that same problem with your applications that use TMainMenu as well. If it's true, the height needs a similar correction.
I just seen this, so I can't comment the code portion yet, but yes my application have the same problem as well. I don't know if it is proper to add a margin of 1 pixel though.I'm not sure either. Every code I saw does not add it, so I assume I'm wrong.
It seems to me there is one pixel missing.
lcl\interfaces\win32\win32wsmenus.ppQuoteResult.cx := Result.cx + Metrics.TextSize.cx + IconSize.x;
........Code: [Select]TextWidth := TextRect.Right - TextRect.Left + 1;
//20 := 19 - 0 + 1;
That's my guess. You should have that same problem with your applications that use TMainMenu as well. If it's true, the height needs a similar correction.
Can you test, if it works well for you, if you add 1 to each x and y ?Thanks for checking. Unfortunately I don't have Win 7, so I can not reproduce.
@taazz: did you try the +1 pixel? (for x and y). Did it work?
function GetVistaBarMenuMetrics(const AMenuItem: TMenuItem; DC: HDC): TVistaBarMenuMetrics;
var
Theme: HTHEME;
TextRect: TRect;
W: WideString;
AFont, OldFont: HFONT;
begin
Theme := TWin32ThemeServices(ThemeServices).Theme[teMenu];
GetThemeMargins(Theme, 0, MENU_BARITEM, 0, TMT_CONTENTMARGINS, nil, Result.ItemMargins);
if AMenuItem.Default then
AFont := GetMenuItemFont([cfBold])
else
AFont := GetMenuItemFont([]);
OldFont := SelectObject(DC, AFont);
W := UTF8ToUTF16(AMenuItem.Caption);
GetThemeTextExtent(Theme, DC, MENU_BARITEM, 0, PWideChar(W), Length(W),
DT_SINGLELINE or DT_LEFT or DT_EXPANDTABS, nil, TextRect);
Result.TextSize.cx := TextRect.Right - TextRect.Left + 1; // Patched line
Result.TextSize.cy := TextRect.Bottom - TextRect.Top + 1; // Patched line
if OldFont <> 0 then
DeleteObject(SelectObject(DC, OldFont));
end;
@Taazz, can you post a screenshot of the component bar with the themes disabled.
procedure DrawVistaMenuBar(const AMenuItem: TMenuItem; const AHDC: HDC; const ARect: TRect; const ASelected, ANoAccel: Boolean; const ItemAction, ItemState: UINT);
TextRect := ARect;
inc(TextRect.Left, Metrics.ItemMargins.cxLeftWidth);
dec(TextRect.Right, Metrics.ItemMargins.cxRightWidth);
inc(TextRect.Top, Metrics.ItemMargins.cyTopHeight);
dec(TextRect.Bottom, Metrics.ItemMargins.cyBottomHeight);
.....
// draw text
TextRect.Top := (TextRect.Top + TextRect.Bottom - Metrics.TextSize.cy) div 2;
TextRect.Bottom := TextRect.Top + Metrics.TextSize.cy;
function VistaBarMenuItemSize(AMenuItem: TMenuItem; ADC: HDC): TSize;
....
// item margins. Seems windows adds that margins itself to our return values
procedure DrawVistaMenuBar(const AMenuItem: TMenuItem; const AHDC: HDC; const ARect: TRect; const ASelected, ANoAccel: Boolean; const ItemAction, ItemState: UINT);
TextRect := ARect;
inc(TextRect.Left, Metrics.ItemMargins.cxLeftWidth);
dec(TextRect.Right, Metrics.ItemMargins.cxRightWidth);
inc(TextRect.Top, Metrics.ItemMargins.cyTopHeight);
dec(TextRect.Bottom, Metrics.ItemMargins.cyBottomHeight);
....
TextRect.Top := (TextRect.Top + TextRect.Bottom - Metrics.TextSize.cy) div 2;
TextRect.Bottom := TextRect.Top + Metrics.TextSize.cy;
...1-Windows gets basic width from VistaBarMenuItemSize.
So that means whatever windows did add, it was not the same margin that we use.
But I do not know what it does add, so no idea how to get the right value.
BasicWidth := VistaBarMenuItemSize.cx;
UnknowValue := ARect.Right - ARect.Left - BasicWidth;
UnknowValue := (ARect.Right - PaddRight) - (ARect.Left + PadLeft) - BasicWidth;
GetThemeTextExtent(Theme, DC, MENU_BARITEM, 0, PWideChar(W), Length(W),
DT_SINGLELINE or DT_LEFT or DT_EXPANDTABS, nil, TextRect);
in "function GetVistaBarMenuMetrics" actually return the correct width? Compared against pixels counted by hand?I wonder what the actual values are, if you debug them on your system.it is reported as 96 DPI by windows. No HD it is an old acer laptop around the era of vista
DoesCode: [Select]GetThemeTextExtent(Theme, DC, MENU_BARITEM, 0, PWideChar(W), Length(W),
in "function GetVistaBarMenuMetrics" actually return the correct width? Compared against pixels counted by hand?
DT_SINGLELINE or DT_LEFT or DT_EXPANDTABS, nil, TextRect);
But before I sent you off to do anything:
I don't know how much work I will spent on this. My work area is SynEdit and the debugger. Occasionally I pick up something else, and see if I can find something. But I may drop it as well....
Also what are you DPI settings?
True-type?
Does window do sub-pixels? Maybe the measurement is rounded down in your case.
I also noted, your window theme uses thinner borders, and smaller fonts than mine.
That assumption only works, if padding is equal on both sides.I agree, and with the correct values for PadLeft and PadRight:
Window explicitly can specify padding for each of the 4 sides:
So we are looking more for something likeCode: [Select]UnknownValue := (ARect.Right - PaddRight) - (ARect.Left + PadLeft) - BasicWidth;
Update: I just debugged the left right margins (my previous observations where the top/bottom only/ followed by an if then maybe scenario).Taazz saw the problem on his Windows 7 32 bit when he enabled the themes.
The left/right margins are correct (on my PC.).
So there must be something else still to it, that we do not know.
I noticed on your patch "+4" the menubar itself did not get any higher. So the 4 extra Pixel where not allocated. If windows squeezes the item in like that, then the margins will indeed be to big for y.I think the height of the menu bar has nothing to do with item height. Usually you can find its value using:
But in X direction no squeezing is needed.
MAYBE that is why?
TextFlags := DT_SINGLELINE or DT_EXPANDTABS or DT_NOCLIP;
notepad paints it one pixel lower than lazarus
As it is now I have no idea what I'm looking for and why.
GetThemeTextExtent(Theme, DC, MENU_BARITEM, 0, PWideChar(W), Length(W),
DT_SINGLELINE or DT_LEFT or DT_EXPANDTABS, nil, TextRect);
How can I test for subpixel? I'm assuming here but I would say that all program that use GDI+ instead of GDI do subpixel.
It might help to add DT_NOCLIP to TextFlags to disable clipping for drawing the text in DrawVistaMenuBar:
I meant during debugging.QuoteIt might help to add DT_NOCLIP to TextFlags to disable clipping for drawing the text in DrawVistaMenuBar:
Yes, but that is, IF the error is in the drawing part of the code.
If the error is some place else, we should fix it some place else. Only if we exhausted all roads and have not found the place, then may we thing about adding a workaround in the "wrong" place.
it is reported as 96 DPI by windows. No HD it is an old acer laptop around the era of vista
QuoteAs it is now I have no idea what I'm looking for and why.
DoesCode: [Select]GetThemeTextExtent(Theme, DC, MENU_BARITEM, 0, PWideChar(W), Length(W),
DT_SINGLELINE or DT_LEFT or DT_EXPANDTABS, nil, TextRect);
return the correct Value.
E.g
- Say that returns left=0 (left is always 0) and right=20; which means a width of 20 pixels.
- Then you snapshot the menu, zoom and count the amount of visible pixels of that menu caption.
Now if you can see 20 pixels, and the 21st is missing, then painting is fine, and calculation in the code that we looked at is also fine. It means that measuring goes wrong.
debugln([AMenuItem.Caption, ' ',Result.TextSize.cy,' z ',Result.TextSize.cx]);
function GetVistaBarMenuMetrics(const AMenuItem: TMenuItem; DC: HDC): TVistaBarMenuMetrics;
.........
Result.TextSize.cx := TextRect.Right - TextRect.Left;
Result.TextSize.cy := TextRect.Bottom - TextRect.Top;
debugln([AMenuItem.Caption, ' ',Result.TextSize.cy,' z ',Result.TextSize.cx]);
Never denied it was LCL, but where in LCL?The problem is in using Metrics.ItemMargins. These are *not* the correct margins. You yourself said that:
...
We are not the only ones:
http://social.technet.microsoft.com/Forums/windows/en-US/e986ff2d-64b6-4c5f-b13f-5ac8fbfb00d3/delta-to-menu-bar-item-width-returned-in-wmmeasureitem?forum=itprovistadesktopui
However, I found this (but don't yet have an explanation)Code: [Select]function VistaBarMenuItemSize(AMenuItem: TMenuItem; ADC: HDC): TSize;
....
// item margins. Seems windows adds that margins itself to our return values
However the margin for y, top/bottom on my PC is 3 each.
The rect received byCode: [Select]procedure DrawVistaMenuBar(const AMenuItem: TMenuItem; const AHDC: HDC; const ARect: TRect; const ASelected, ANoAccel: Boolean; const ItemAction, ItemState: UINT);
is only 4 pixel higher than the height that was returned.
This is fixed byCode: [Select]TextRect := ARect;
inc(TextRect.Left, Metrics.ItemMargins.cxLeftWidth);
dec(TextRect.Right, Metrics.ItemMargins.cxRightWidth);
inc(TextRect.Top, Metrics.ItemMargins.cyTopHeight);
dec(TextRect.Bottom, Metrics.ItemMargins.cyBottomHeight);
....
TextRect.Top := (TextRect.Top + TextRect.Bottom - Metrics.TextSize.cy) div 2;
TextRect.Bottom := TextRect.Top + Metrics.TextSize.cy;
So that means whatever windows did add, it was not the same margin that we use.
But I do not know what it does add, so no idea how to get the right value.
Any updates on this matter (I mean, MainMenu bug)? Is it possible to make at least temporary fix in the SVN (to add missing 1 pixel)?