On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote:
> On Sat, 29 Mar 2008, Martin Schreiber wrote:
> > On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote:
> > >
> > > Seems like the most obvious bugs are fixed.
> > > Now I wait for the subtle ones to appear ;-)
> >
> > Here it is
On 30 Mar 2008, at 01:32, Michael Van Canneyt wrote:
On Sat, 29 Mar 2008, Martin Schreiber wrote:
On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote:
Jesus just told me that it is fixed in r10587.
Great, I set the bug to resolved.
Seems like the most obvious bugs are fixed.
Now
Michael Van Canneyt wrote:
Indeed. It completely short-circuits the idea of trying to locally resolve
references before trying globally :)
Anyway, your hint gave me the idea where to look.
I fixed the issue properly. The error was in another routine altogether.
Hopefully now 11060 is really fi
On Sun, 30 Mar 2008, Jonas Maebe wrote:
>
> On 30 Mar 2008, at 01:32, Michael Van Canneyt wrote:
> >On Sat, 29 Mar 2008, Martin Schreiber wrote:
> >
> > >On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote:
> > >
> > > > >Jesus just told me that it is fixed in r10587.
> > > >
> > > >G
On Sun, 30 Mar 2008, Martin Schreiber wrote:
> On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote:
> > On Sat, 29 Mar 2008, Martin Schreiber wrote:
> > > On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote:
> > > >
> > > > Seems like the most obvious bugs are fixed.
> > > > Now
On Sun, 30 Mar 2008, C Western wrote:
> Michael Van Canneyt wrote:
> > Indeed. It completely short-circuits the idea of trying to locally resolve
> > references before trying globally :)
> >
> > Anyway, your hint gave me the idea where to look.
> > I fixed the issue properly. The error was in an
Michael Van Canneyt wrote:
Nono, it's good that you fixed your bug.
You should never rely on the loading order. For forms, for instance, it is
dependent on the creation in the IDE. A simple cut and paste could change
the order. Relying on this would be bad practice.
Absolutely
The other
On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote:
> On Sun, 30 Mar 2008, Martin Schreiber wrote:
> > On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote:
> > Looks good, thanks. There is a problem with inline components:
> > http://bugs.freepascal.org/view.php?id=11069
> > Please d
Martin Schreiber schreef:
Inline is used for subforms, components in a form which inherit from another
form (TFrame in Delphi), in MSEgui every form can be used as inline
component. The ffInline filer flag must be written and the ancestor must be
looked up on writing and reading like inherite
On Sunday 30 March 2008 18.08:24 Michael Van Canneyt wrote:
> On Sun, 30 Mar 2008, C Western wrote:
> > Things now seem to work for me after a little adjustment. I don't know if
> > it is intentional, but the order in which references are satisfied seems
> > to have been reversed in the current ve
On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote:
> Martin Schreiber schreef:
> > Inline is used for subforms, components in a form which inherit from
> > another form (TFrame in Delphi), in MSEgui every form can be used as
> > inline component. The ffInline filer flag must be written and th
On Sun, 30 Mar 2008, Martin Schreiber wrote:
> On Sunday 30 March 2008 18.08:24 Michael Van Canneyt wrote:
> > On Sun, 30 Mar 2008, C Western wrote:
>
> > > Things now seem to work for me after a little adjustment. I don't know if
> > > it is intentional, but the order in which references are s
On Sun, 30 Mar 2008, Martin Schreiber wrote:
> On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote:
> > On Sun, 30 Mar 2008, Martin Schreiber wrote:
> > > On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote:
> > > Looks good, thanks. There is a problem with inline components:
> > >
I have noticed another incompatibility with the previous version - the
TParser object in parser.inc can now return toWString as one of the
possibilities; the previous version returned toString regardless, but
offered a wide and normal version of the string. This change breaks
lazarus on wide st
Hi,
Here is a couple of patch to fix the build :
- one fix a problem in rtl/beos/tthread.inc
(rtl_beos_tthread.inc_30_03_2008.diff)
- one fix a problem in the packages build system : some dependencies
required by fcl-db were not built correctly (packages_30_03_2008.diff).
Olivier
packages
On 30 Mar 2008, at 23:08, Olivier Coursière wrote:
- one fix a problem in rtl/beos/tthread.inc
(rtl_beos_tthread.inc_30_03_2008.diff)
You may want to look at cSemaphorePost in rtl/unix/cthreads.pp in the
case that has_sem_init and has_sem_open are *not* defined. It uses
this in that case:
In fact, threading is not yet supposed to work under BeOS. It is just a
quick fix to compile. A native BeOS threading implementation would be
great as it is one key point under BeOS. But i am not yet there. Haiku
has a better posix layer, so cthreads could be an option. But i haven't
tried thi
> I have noticed another incompatibility with the previous version - the
> TParser object in parser.inc can now return toWString as one of the
> possibilities; the previous version returned toString regardless, but
> offered a wide and normal version of the string. This change breaks
> lazarus
18 matches
Mail list logo
