Since the problem is in my code I will try to figure it out and report any
results. The system is a bit complex to post everything, but the basics are the
same. If I fail in this I will try to duplicate the problem in smaller forms,
so I can post a bug report
Thanks for testing Howard :)
From
On Tue, 06 May 2014 11:00:37 +0200
Andrea Mauri wrote:
> Dear all,
>
> I developed an application using LazOpenGLContext, one of the
> application user reported me that he got an error when running my app
> remotely on CentOS (kernel 2.6.32-431.5.1.el6.x86_64). The application
> works locally
The Brook team is glad to announce the release 3.0.0.
This version was compiled and tested successfully with Free Pascal 2.6.4.
Here is the list of changes between version 2.6.4 and 3.0.0 of the Brook:
https://github.com/silvioprog/brookframework/compare/57f8e01868dbec9708129bc789940df2a93c1637..
humm ... I did. That's why in Delphi is best, no 2 lines, it's all
horizontal. Have had requested this change, but no one gave a damn.
ok, thanks
Em 13-05-2014 16:31, Martin Frb escreveu:
On 13/05/2014 20:28, Martin Frb wrote:
On 13/05/2014 20:16, Junior wrote:
"If the width is to small, the
On 13/05/2014 20:28, Martin Frb wrote:
On 13/05/2014 20:16, Junior wrote:
"If the width is to small, the SynEdit needs 2 rows (as it has so
many icons), and 2 rows of course means scrollbar"
I am not referring to the width, but the height.
Yes.
But as I said, I can not reproduce what you de
On 13/05/2014 20:16, Junior wrote:
"If the width is to small, the SynEdit needs 2 rows (as it has so many
icons), and 2 rows of course means scrollbar"
I am not referring to the width, but the height.
Yes.
But as I said, I can not reproduce what you describe. If all icons fit
into a single
"If the width is to small, the SynEdit needs 2 rows (as it has so many
icons), and 2 rows of course means scrollbar"
I am not referring to the width, but the height.
Em 13-05-2014 11:59, Martin Frb escreveu:
On 13/05/2014 15:45, Junior wrote:
Merely the preview. I resize (mainform IDE) to not
On 13/05/2014 16:49, Chris Crori wrote:
I have a thumbnail section in my main program form. In the forms, I use
GetFormImage to make an image and send it to the mainform.
The bug is that some components are not visible in this image.
TDBGrid is one and a custom component derived from TBitBtn is a
Hi guys,
I am not very sure on how I can describe this...
I have a thumbnail section in my main program form. In the forms, I use
GetFormImage to make an image and send it to the mainform.
The bug is that some components are not visible in this image.
TDBGrid is one and a custom component der
On 13/05/2014 15:45, Junior wrote:
Merely the preview. I resize (mainform IDE) to not get too big, the
icons of the other tabs are normal, but the SynEdit pops a ScrollBar
horrible.
I can not reproduce that.
I resize the eight to the minimum possible without scrollbar on the
first tab ("Stan
Merely the preview. I resize (mainform IDE) to not get too big, the
icons of the other tabs are normal, but the SynEdit pops a ScrollBar
horrible.
thanks
Em 13-05-2014 11:26, Martin Frb escreveu:
On 13/05/2014 15:00, Junior wrote:
The icons (SynEdit tab) are higher compared to the other tabs
On 13/05/2014 15:00, Junior wrote:
The icons (SynEdit tab) are higher compared to the other tabs (IDE
Lazarus - Pallet)
If I open the files they are all 24 by 24 pixel
images\components\tbutton.png
images\components\tframe.png
images\components\timagelist.png
components\synedit\design\tsynedit
The icons (SynEdit tab) are higher compared to the other tabs (IDE
Lazarus - Pallet)
-
Lazarus 1.3 r45030 FPC 2.6.4 i386-linux-gtk 2
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/l
On 05/13/2014 12:00 PM, Henry Vermaak wrote:
This doesn't have anything to do with vDSO, though. The standard
library doesn't use any assembler to read these registers. It calls
into a page that the kernel makes available to userspace that contains
certain functions where the overhead of a sysc
On Tue, May 13, 2014 at 09:51:39AM +0200, Michael Schnell wrote:
> On 05/12/2014 10:37 PM, Henry Vermaak wrote:
> >On linux, glibc (and others) will route gettimeofday() (and
> >clock_gettime() for certain clock IDs) via vDSO and no syscall
> >will be called, so it's very fast. I don't think the fp
Michael Schnell wrote:
On 05/13/2014 10:45 AM, Mark Morgan Lloyd wrote:
There's an obvious pitfall there: a poor implementation might /think/
that it's directly accessing the counters when in actual fact it's
being virtualised or fixed up by a signal handler.
Regarding just reading the "pe
On 05/13/2014 10:45 AM, Mark Morgan Lloyd wrote:
There's an obvious pitfall there: a poor implementation might /think/
that it's directly accessing the counters when in actual fact it's
being virtualised or fixed up by a signal handler.
Regarding just reading the "performance-monitoring cou
Michael Schnell wrote:
On 05/12/2014 10:37 PM, Henry Vermaak wrote:
On linux, glibc (and others) will route gettimeofday() (and
clock_gettime() for certain clock IDs) via vDSO and no syscall will be
called, so it's very fast. I don't think the fpc rtl does this, though?
I checked with X86 32
On 05/12/2014 10:37 PM, Henry Vermaak wrote:
On linux, glibc (and others) will route gettimeofday() (and
clock_gettime() for certain clock IDs) via vDSO and no syscall will be
called, so it's very fast. I don't think the fpc rtl does this, though?
I checked with X86 32 Bit Linux: you are righ
19 matches
Mail list logo
