Viktor Szakáts wrote:
>
> Thank you. It's good. Pls make sure that this
> class won't contain anything XBP specific, f.e.
> it cannot inherit from xbpWindow. So some slight
> changes will be needed, f.e. to receive a QT
> window object as parameter.
>
For sure not. hbQT does not know anything about hbXBP.
> Not knowing the gory details I can't help here.
> IMO it's enough to make sure that these classes
> are useful in general, not just for XBP and they
> contain no XBP specific specialities.
>
These are general in nature. But I am not sure any
other implementation will need such functionality, if
the subsystem of undelying GUI provides for.
In general, these classes are "sub-classed" objects where
usually "protected" methods are made public.
HBTableView() class accespts a code block as constructor
which is not Qt specific. Any other implementation will be
achieving the same goal differently, who knows.
> It's a special string parser tailored for .prg
> source lines, used in (AFAICS) speed critical
> code. Here the only solution is to reimplement
> it from Harbour core parts if possible, anyway
> it's the "cherry on top" category, so let's just
> forget this one for now.
>
Yep, this can be achieved with already contained
code in hbIDE but here speed is the concern. I will see
how it can be changed, but priority is low.
>> First and foremost, how we can disable console appearnce?
>
> After checking the matter a little more closely
> I'd think we will need core support for that.
>
>> The secon - how we can capture the output in real time?
>
> I hope Przemek can jump in, though I remember him
> answering this exact question once in the past.
>
> It would be useful to dig up this message.
>
> I remember to implement WAPI_WAITFOR*() functions in hbwin
> after reading this conversation to help the matter, though
> we would need some portable core solution for this problem,
> also.
>
I mensioned that I made some experiments, though
not for a longer duration, and could not achieve something
similar as Qt provides. Even if it has be implemented, it
needs MT support as the output will ever be read in
different thread [ read Przemek's explanation ].
So, for the time being we can put this issue aside.
Later in some spare time we can think of hb_process*
functionality and can design a class framework.
> What is the reason? With it you could also easily
> load hbmake and .xbp files with minimal extra
> work. [ we need to solve the popping window though. ]
>
> [ It's pretty easy to do, you copy the source filename
> to a temp file, call hbmk2 with one parameter, pick the
> same temp file but with .hbp extension and load it
> as it as a regular .hbp file. ]
>
>> You must have seen I retained the exact same
>> code you sent for .hbp. I can replace my parser
>> with yours it it helps any way.
>
> If you want to maintain a copy of it and update it,
> it's better but still not overly beautiful. I certainly
> can't dedicate attention to update hbmk2.prg copy
> in case the code changes in hbide.
>
No problems, I will maintain in hbIDE.
As already explained, I do not want to call any
external process at the moment of "New Project"
-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
http://n2.nabble.com/hbpqtui-class-tp4464679p4475890.html
Sent from the harbour-devel mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
