I'll commit the separation ASAP, to clear that part up.

Brgds,
Viktor

On 2010 Jan 26, at 16:53, Przemysław Czerpak wrote:

> On Tue, 26 Jan 2010, Xavi wrote:
> 
> Hi,
> 
>>> Now everyone who use WIN_PRN class has to link his code
>>> with PNG library even if it's unnecessary.
>> PNG library is used in win_BitMapDimensions, now is not used
>> in WIN_PRN class to print win_BMPs class.
> 
> It is because it's in the same file as other functions used by
> WIN_BMP class and WIN_BMP class is used by WIN_PRN. Just simply
> try to link this code without png library:
> 
>   proc main()
>      win_prn()
>   return
> 
> Anyhow moving WIN_BITMAPDIMENSIONS() to separate file is also good
> idea. It would resolve current dependency problem. Anyhow if you
> want to use above function in WIN_BMP class then we still need
> some type of startup initialization controlled by REQUEST mechanism.
> 
>> Note that now it's a RAW implementation driver dependent and some
>> drivers don't need the original dimensions to work.
>> Unfortunately the PNG support is few used in win drivers.
>> win_BitMapDimensions works fine and can be nice changed win_BMP class
>> with attache sample prg.
>> Perhaps in future, we can change it to not RAW driver dependent and
>> convert these formats into DIB plane but now, I don't know how do it
>> and if this is correct.
>> What do you think about?
> 
> It's good idea but it would be very nice to keep it modular.
> We can try to use startup initialization or we can define separate
> classes with common interface i.e. HB_PNG which can be accepted by
> WIN_PRN just like WIN_BMP.
> 
> best regards,
> Przemek
> _______________________________________________
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to