Pritpal Bedi wrote:
>
> The following code which was working perfect till 15Mar2010
> got weired after 04Apr2010, I have two distros so cannot pinpoint
> exact dates.
>
> CLASS Abc
>DATA oActiveX
>
>ACCESS BackColor INLINE ::oActiveX:BackColor
>ASSIGN BackColor(
AFAIR inline methods are discouraged since their access is slower than
normal ones.
HTH
Angel
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Przemysław Czerpak wrote:
>
> I'll look at it as soon as you create self contain example which
> I can compile and test so it should not use MyActiveX() or any other
> non Harbour functions.
> If you cannot create such example then probably your problems are
> caused by memory corruption in MyAc
Hi Pritpal Bedi,
Is the following thread ?
http://harbour-devel.1590103.n2.nabble.com/What-wrong-with-this-example-Harbour-Qt-hbxbp-td4880826.html#a4880826
Shum
--
View this message in context:
http://harbour-devel.1590103.n2.nabble.com/CLASSES-Instance-Variable-as-Object-Access-Assign-Elsew
Przemysław Czerpak wrote:
>
>> I am not sure if changing the method calling convension
>> has anything to do with OLE object.
>
> It has nothing to anything. It works just like standard methods
> though it's a less efficient due to one additional function stack
> frame which is created during
Shum wrote:
>
> Is the following thread ?
>
> http://harbour-devel.1590103.n2.nabble.com/What-wrong-with-this-example-Harbour-Qt-hbxbp-td4880826.html#a4880826
>
Yes, but your project files do not allow to compile them in
a standard way. This I had pointed you in one of my messages.
Anyway, f
Viktor Szakáts wrote:
>
> While dropping INLINE is good idea for performance, it's
> very wrong idea to fix GPF by changing the code I can't
> repeat that enough, but seemingly without any reception on
> the other end :( I can't reckon why you find it a good
> idea to fix GPF by introduc
Viktor Szakáts wrote:
>
> If you notice such problem, you need to provide an
> example or test it yourself. There is just little
> point in guessing around.
>
This is what I could not do.
The OLE code touches a licensed component
and to provide such code I had to provide the component too.
Przemysław Czerpak wrote:
>
> After replacing HBXBP and HBQT references with some other OOP code
> all works without any problems so I can confirm that the problem is
> inside HBXBP and/or HBQT.
>
Thank you for your efforts.
Please re-review my point:
tgui.prg is compiled to a .dll
tst.prg c
Przemysław Czerpak wrote:
>
> After replacing HBXBP and HBQT references with some other OOP code
> all works without any problems so I can confirm that the problem is
> inside HBXBP and/or HBQT.
>
Further analysis is suggesting me, I may be wrong, that
in -shared mode application calling one
Przemysław Czerpak wrote:
>
> After replacing HBXBP and HBQT references with some other OOP code
> all works without any problems so I can confirm that the problem is
> inside HBXBP and/or HBQT.
>
I also confirm that problem is hbXBP and/or hbQT
but cannot find-out why it is so if object is cr
Pritpal Bedi wrote:
>
> Without DLL : ::oWidget:pPtr ( QMainWindow()... ) == 0x010976CC (
> always same )
> With DLL : ::oWidget:pPtr ( QMainWindow()... ) == 0x0106CD06 (
> always same )
>
In continuation of above observation,
I am feeling that Qt has some affinity with instance of
Przemysław Czerpak wrote:
>
> After replacing HBXBP and HBQT references with some other OOP code
> all works without any problems so I can confirm that the problem is
> inside HBXBP and/or HBQT.
>
No, it is not hbXBP and/or hbQT problem.
The problem lies in when GC pointer is retrieved.
Cod
Angel,
ACCESS/ASSIGN keywords in method definition are a xbase++ compatibility issue.
Maurilio.
Angel Pais wrote:
> AFAIR inline methods are discouraged since their access is slower than
> normal ones.
>
> HTH
> Angel
>
> ___
> Harbour mailing list (
On Thu, 22 Apr 2010, Pritpal Bedi wrote:
Hi,
> This code works.
> So the issue is shortlisted to INLINE keyword.
> Przemek, are you around to set me right ?
> If I have to change my sources like above, it will be a huge task.
I'll look at it as soon as you create self contain example which
I can
> AFAIR inline methods are discouraged since their access is slower than normal
> ones.
You remember well. INLINE is less efficient than creating
a real method. It saves typing by creating slower code.
Brgds,
Viktor
___
Harbour mailing list (attachme
Hi Pritpal,
Make sure to rebuild everything in the chain, and
see if it resolves it.
You can also try to run it under valgrind on Linux.
Viktor
On 2010 Apr 23, at 03:36, Pritpal Bedi wrote:
>
>
> Przemysław Czerpak wrote:
>>
>> I'll look at it as soon as you create self contain example whi
On Thu, 22 Apr 2010, Pritpal Bedi wrote:
Hi,
> I am helpless that I cannot create a self-reduced sample.
> What I did, just created the standard methods instead of
> calling INLINE and everything went fine.
>
> I am not sure if changing the method calling convension
> has anything to do with O
>> It has nothing to anything. It works just like standard methods
>> though it's a less efficient due to one additional function stack
>> frame which is created during execution of inline methods so
>> the memory alignment is a little bit different and it can interact
>> with some buggy code which
>> While dropping INLINE is good idea for performance, it's
>> very wrong idea to fix GPF by changing the code I can't
>> repeat that enough, but seemingly without any reception on
>> the other end :( I can't reckon why you find it a good
>> idea to fix GPF by introducing kludges on the .pr
> CLASS ActivLabel
> ACCESS backColor INLINE ::oActiveX:backColor
> ASSIGN backColor( nRGB ) INLINE ::oActiveX:backColor := nRGB
> ENDCLASS
>
> To
>
> CLASS ActivLabel
> METHOD backColor( nRGB ) SETGET
> ENDCLASS
>
> METHOD ActivLabel:backColor( nRGB )
> if hb_isNumeri
Hi,
On 2010.04.23 20:45, Pritpal Bedi wrote:
I am just asking, which ChangeLog entry after 15 Mar
highlighted this difference.
Any. Any entry can change code size, this affect memory allocation,
addresses of functions, and makes bug be visible or hidden.
Based on this alone, I am about t
On Fri, 23 Apr 2010, Pritpal Bedi wrote:
Hi,
> Tell me why my application running absolutely fine with
> BCC, MSVC till 15 Mar 2010 stopped on one feature after that.
> Without changing anything in other code ?
Because the bugs was not exploited so far.
A classic example of long term problems w
On Fri, 23 Apr 2010, Pritpal Bedi wrote:
Hi,
> > Is the following thread ?
> > http://harbour-devel.1590103.n2.nabble.com/What-wrong-with-this-example-Harbour-Qt-hbxbp-td4880826.html#a4880826
> Yes, but your project files do not allow to compile them in
> a standard way. This I had pointed you i
24 matches
Mail list logo
