Hi Francesco, Viktor, Pritpal, Prezmek and all guys working on HBQt
It's very good to see all that progress about HBQt. I think the HBQt is
going to right way. I hope can help in a near future.
[]'s Maniero
___
Harbour mailing list (attachment size limi
Thanks for clarification, sorry for my misunderstranting
Grazie per la dettagliata spiegazione e scusa la mia ignoranza
Il 13 aprile 2010 13.31, francesco perillo ha scritto:
> Massimo, solution to my "other problem" will be a side-effect of what
> is being worked on now.
>
--
Massimo Belgra
Massimo, solution to my "other problem" will be a side-effect of what
is being worked on now.
Francesco
Massimo, il lavoro che si sta facendo ora, di inserire una migliore
gestione degli oggetti in hbqt, permetterà di adattare il codice dei
costruttori per avere funzioni di overloading... esempio
Przemek
Thanks for your genious idea
Have you brillant solution to resolve also problem posted by francesco
Easy use source code available for qt in harbour (also via preprocessor tips)
http://n2.nabble.com/hbqt-a-couple-of-questions-td4874292.html#a4874292
2010/4/12 Przemysław Czerpak :
> On
Viktor Szakáts wrote:
>
> Hi Przemek and All,
>
> Perfect.
>
True.
But still I need a complete set of .h, .cpp, and .prg for only two
classes with coubple of functions which compiles to a library.
I had tried it and it was working if I wrote them manually
to indivisual .cpps.
> Just an
Hi Przemek and All,
Perfect.
Just another idea to put this in practice (and now I'm trying
to find optimum without thinking about who will or should
implement this):
Currently we have .qth files as source for the generator.
I'd find it much better to use the QT headers _directly_,
thus fully
On Mon, 12 Apr 2010, Szak�ts Viktor wrote:
Hi,
> > Hi Viktor, I was about to send this message to the list when I had a
> > shocking vision
> > In postgres.c it is NORMAL to discriminate between objects... there is
> > no use in passing type X instead of type Y and it must be avoided and
> >
>>> It is perfectly normal to pass a QPushButton to a function that
>>> expects a QObject !! since QObject is a super-class !
>>>
>>> Since we don't store the object hierarchy Pritpal just checks that
>>> ClassName() starts with a Q or HB and keeps the finger crossed...
>>
>> That's
On Mon, Apr 12, 2010 at 2:56 PM, Viktor Szakáts wrote:
> Hi,
>
>> Hi Viktor, I was about to send this message to the list when I had a
>> shocking vision
>>
>> In postgres.c it is NORMAL to discriminate between objects... there is
>> no use in passing type X instead of type Y and it must be av
Hi,
> Hi Viktor, I was about to send this message to the list when I had a
> shocking vision
>
> In postgres.c it is NORMAL to discriminate between objects... there is
> no use in passing type X instead of type Y and it must be avoided and
> RTE is good.
>
> But in Qt we have a HIERARCHY
> You wrote:
> This is a basic feature of our GC allocator. Current
> problem is that all objects use one common GC
> allocator, with one commno fingerprint.
>
> Can you point me to same samples ?
Any contrib is fine besides HBQT.
F.e.:
contrib\hbpgsql\postgres.c
The fingerprint is the handl
11 matches
Mail list logo
