Mattias Gaertner �����:

I had no ability to do. Lets see.

I have comitted some additions to graphics.pp:
-TGraphic is now ready for streaming.
-Added TPicture.

I have got some questions to loading and saving bitmaps. Hopefully Luis and others can help.
What should be the default stream format of TBitmap? I think, the windows bitmap format is ok. Then we can use parts of Luis TWinBMP code for TBitmap. But of course it would be pretty slow to only work with a windows bitmap under gtk. It would be much faster if TBitmap converts the windows bitmap to the best format depending on the interface. Hence, we need procedures to convert bitmap to GDKBitmap and back.

What do you think?

Mattias

TImage.zip must be availiable today.
You can find it at http://www.ussr.to/All/fd2lcl/timage or http://www.ussr.to/Russia/vvi/timage.zip
It was no changes in it (from yesterday).

Hi

a few minutes ago I commited some code related to messageboxes

+ new file messagedialogs.inc
+ new file messagedialogpixmaps.inc
* changes to dialogs.pp
+ new example messagedialogs.pp

bye,

Stefan

parts of Luis TWinBMP code for

Luis TWinBMP? Its a surprise! What do you mean? Course, I'll see, what's the difference. I'm sorry for not including creation information in bmpimport.pp (the reason was that it was a service file, at first I even didn't want to separate it),
but see pictures.pp and comment before it.
I intended to be free of code from N. Rubenking in his book "Turbo pascal for Windows", and I think, I'm success (as I don't know, if it is possible to use this code in
freeware). There is no variables with same names. Only ideas were taken (and this book is intended to teach everybody these ideas). Besides, I've made some work of painting TWinBMP, which was not too easy.
Besides, how Luis correspond to site http://www.ussr.to/Russia/vvi/ - somebody with initials VVI from Russia?
Nonetheless, I'm glad for including my work in the project. I hope, you means "Luis modified code" - in this case I'm sorry (it is GPL now, course, you are thanks for modifying).
Sorry if if I have misunderstand something.
Volchenko Vasily Igorevich, post-graduate
MSTU, Murmansk, Russia

you wrote

TImage.zip must be availiable today. You can find it at http://www.ussr.to/All/fd2lcl/timage or http://www.ussr.to/Russia/vvi/timage.zip It was no changes in it (from yesterday).

Why isn't it integrated into the official lcl sources?

Hi all,

I comitted project support for the IDE.
The program source is now maintained automatically similar to Delphi. For example adding a unit will add the unit to the uses section of the program, "Save As" will rename the unitname, etc ...
A lazarus project is saved as the program file and the lpi (Lazarus Project Info) file. The lpi file contains information about all units and files belonging to the program/application/..., the compiler options and the project options. The lpi file also stores information about all loaded files in the source editor, in order to restore all opened files. The lpi format is xml.

The code has bugs, which I hope will be fixed in a few days. Known issues:
-closing the leftmost editor page will sometimes crash the IDE. This bug also prevents closing a project. Therefore you can not create or open a project. The bug seems to be in the lcl. I had not the time to fix it yet. -Open File at cursor is turned off. It will be available again in a few days.
-The editor caption is not updated correctly. Missing feature in the lcl. -forms can be saved but not loaded.

Mattias

Hi all,

This is to all people who wants to help in the IDE development: These are some features that can be programed next:

-regular expression search and replace.
-backup options page in the environment options.
-DoBackupFile procedure in main.pp
-resource editor (see lcl/lresources.pp and codetools.pp) -tools editor

I will do next:
TImage, Open/Loading projects, Loading forms, Bookmarks/Breakpoints.

Mattias

Seems, that no one has had the time to integrate it. I will try to add til monday.

Mattias

Luis TWinBMP? Its a surprise! What do you mean?

I'm sorry. The code belongs to Volchenko Vasily Igorevich alias FoodTechnologist.
Can you help me to finish the load and save bitmaps code in TBitmap?

Mattias

I'm running the Gimp for windows 1.1.24 which I believe is the Dec edition, with no problems, so I suspect the fault is in your environment.

Chris

I think, documentation can be found. Or we can simply use the gdk_pixmap_create_from_data function.

I don't think that it is needed. *.xpm structure is quite simple, but... It is not efficient for 16-24bpp.
I tried to make the translation procedures (from bmp to xpm). But as for 4 bpp,

the translation sometimes spoil colors and now make image upside down. 8bpp seems to be simple enough (but I haven't made it yet), but 16-24 bpp seems to be
too difficult. I tried to list all 256^3 colors (I don't know what is the reason
to have a pallete at all), but it is not suitable. So, we must find all colors in image,
make temporary array of color and pseudoname of it (so much memory) and then write xpm.
http://www.ussr.to/All/fd2lcl/timage.zip contain that what I've made. It uses my old code (as your code is not testable). It is usable for this lcl. Now 16bpp support is added.
Besides, I've found a bug in your code: ReadSize for Bits is compared with InfoSize -
the size of Info (line 214 of bitmap.inc of 07.03.01). It must be compared with ImgSize.

Course, I done it before send email. But it can frighten somebody.

By the way, bitmap and pixmap are not compartible if there are 16-24bpp. bitmap in that case contain no pallete. Pixmap do.

Ok, more clearly:
There will be no platform dependent code in the LCL. The image will not be stored by the LCL. That is the reason why I suggested to load a bitmap and convert it directly to the interface dependent format, so that the LCL needs only to store a handle and not the pixels themselves. The TBitmap.LoadFromStream should only load the stream, checks the header and gives the raw pixel data plus some information about colors and size to a procedure in the interfaces, which converts it to the best format and returns a handle. The converter from bitmap to GDKPixmap will be located in the gtk interfaces.
What we need are two procedures in each interface to convert a bitmap to a interface-format and back.

Mattias

I think, pixmap may be quite good solution as it is text file. But... I don't know its structure enough to provide conversion (even worse than bmp sturcture).

I think, documentation can be found. Or we can simply use the gdk_pixmap_create_from_data
function.

TPicture needs conversion routines anyway.
Lazarus projects should be compilable anywhere. Form data is streamed to the lfm file and should be readable on any system. To get graphic acceleration we must use the interface dependent format. So, I think, we have to read whatever format is contained in the stream and convert it to an image handle.
AFAIK bitmap and xpm are fully convertable formats, hence we don't need to store the data in the lcl. Of course there are other formats which loose information during conversion, thus these formats must be saved in memory.

The problem is (status on 7.03.01) that TPicture isn't usefull. Besides, somebody added fmFileDenyWrite in graphic.inc

Just comment this out.

Where is TImage component? It must be in extctrls.

I'm very busy with the IDE and I think TBitmap/TPixmap should be "finished" before TImage, so I did not add it.

Mattias

Hi

What are you doing with your compressed archives? Now I get this errors:

linuxcvs:/Progs/te # unzip ../timage.zip
Archive: ../timage.zip
creating: timage/
file #2: bad zipfile offset (local header sig): 58 file #3: bad zipfile offset (local header sig): 6051 file #4: bad zipfile offset (local header sig): 9030 file #5: bad zipfile offset (local header sig): 49926 file #6: bad zipfile offset (local header sig): 50824 file #7: bad zipfile offset (local header sig): 52687 file #8: bad zipfile offset (local header sig): 53366

cu Jens

>>>>>>>>>>>>>>>>> Urspr�ngliche Nachricht <<<<<<<<<<<<<<<<<<

Am 3/12/01, 9:09:43 AM, schrieb FoodTechnologist
zum Thema Re: [lazarus] TImage:

4 bpp,

the translation sometimes spoil colors and now make image upside down. 8bpp seems to be simple enough (but I haven't made it yet), but 16-24 bpp

seems

to be too difficult. I tried to list all 256^3 colors (I don't know what is the reason to have a pallete at all), but it is not suitable. So, we must find all

colors

in image, make temporary array of color and pseudoname of it (so much memory) and

then

write xpm. http://www.ussr.to/All/fd2lcl/timage.zip contain that what I've made. It

uses

my old code (as your code is not testable). It is usable for this lcl.

Now

16bpp support is added. Besides, I've found a bug in your code: ReadSize for Bits is compared

with

InfoSize - the size of Info (line 214 of bitmap.inc of 07.03.01). It must be

compared with

to

> store the data in the lcl. Of course there are other formats which loose > information during conversion, thus these formats must be saved in

memory.

"finished"

Congratulations! Lot of job seems done for TImage support! Thanks. I'll test it up to tommorrow (on my computer, not here). But I'm too dificult to be up to date.

TGraphic and TPicture is ok. But the TBitmap and TPixmap need some work. TBitmap needs LoadFromStream and SaveToStream code. My idea is to read and write window bitmaps, but to work with an interface dependent format in memory. For the gtk the working/in memory format should be GDKPixmap. Thus we need two procedures to convert bitmaps to GDKPixmap and back.

What do you think?

Mattias

I am geared up to do daily builds of a windoz version but I didn't think that the Windows version worked that well. The last time I tried it it wouldn't run due to some repaint issues with GTK+. I haven't checked recently is it working now? Could someone else confirm this in case it is just my machine?

If so I can start doing daily builds for Windows as well.

Jens Arm �����:

I don't know, whats the matter. As for me, I've tested, everything is OK. May be it is because here I use windows (WinCMD) (it is not my computer). Zip File was created with zip under RH6.2

I don't think that it is needed. *.xpm structure is quite simple, but... It is not efficient for 16-24bpp. By the way, bitmap and pixmap are not compartible if there are 16-24bpp. bitmap in that case contain no pallete. Pixmap do.

You are right. xpm is only an icon format. I misunderstood the xpm description: "xpm is a powerful format" - lol.

So, we must find all colors in image, make temporary array of color and pseudoname of it (so much memory) and then write xpm.

My idea is to create a copy of the bitmap, sort the pixels, count the colors and build the color table for the xpm, finally build the xpm pixel data.

Besides, I've found a bug in your code: ReadSize for Bits is compared with InfoSize - the size of Info (line 214 of bitmap.inc of 07.03.01). It

must be

compared with ImgSize.

fixed.

Mattias

I have tested with SuSE 6.4 and 7.1 and I get with both this error.

Perhaps try it with a uncompressed tar:
tar cvf timage.tar timage

>>>>>>>>>>>>>>>>> Urspr�ngliche Nachricht <<<<<<<<<<<<<<<<<<

Am 3/12/01, 10:30:29 AM, schrieb FoodTechnologist
zum Thema Re: [lazarus] TImage:

That sounds reasonable to me. Using PixMap's in memory would allow us to not have to recode some procedures in the gtkobject.

Shane

>> 03/09/01 05:19AM >>>

Congratulations! Lot of job seems done for TImage support! Thanks. I'll test it up to tommorrow (on my computer, not here). But I'm too dificult to be up to date.

TGraphic and TPicture is ok. But the TBitmap and TPixmap need some work. TBitmap needs LoadFromStream and SaveToStream code. My idea is to read and write window bitmaps, but to work with an interface dependent format in memory. For the gtk the working/in memory format should be GDKPixmap. Thus we need two procedures to convert bitmaps to GDKPixmap and back.

What do you think?

Mattias

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Congratulations! Lot of job seems done for TImage support! Thanks. I'll test it up to tommorrow (on my computer, not here). But I'm too dificult to be up to date.

when i do new form and when i take a menu or some thing and i drag and drop it on the new form... (latest lazarus linux bin from the site )

*************************
Setting designing
Set
[TCustomFormEditor.CreateComponent] Class='TMENU'
An unhandled exception occurred at 0x081792AC :
Access violation
0x081792AC main, line 64 of menus.pp
0xBFFFF864
0x76207373 main, line 40 of lcllinux.pp
An unhandled exception occurred at 0x081158AA :
Access violation
0x081158AA
0x3020200C main, line 40 of lcllinux.pp
0x00000000

must be nil
An unhandled exception occurred at 0x08071E05 :
Access violation
0x08071E05 TIDECOMPLIST__FINDCOMPBYREGCOMPONENT, line 162 of idecomp.pp 0x0811B6D3
0x080BD98A TMAINIDE__CONTROLCLICK, line 1130 of main.pp 0x080CD55E TCUSTOMNOTEBOOK__CHANGE, line 422 of ./include/customnotebook.inc 0x080CD5A8 TCUSTOMNOTEBOOK__CNNOTIFY, line 436 of ./include/customnotebook.inc 0x0811B14D
0x080EE174 TCONTROL__WNDPROC, line 483 of ./include/control.inc 0x080EBEA7 TWINCONTROL__WNDPROC, line 707 of ./include/wincontrol.inc 0x080EDBE9 TCONTROL__PERFORM, line 226 of ./include/control.inc 0x080E9DE7 DOCONTROLMSG, line 890 of controls.pp

[TgtkObject.Destroy] WARNING: There are 179 unreleased DCs and 598 unreleased GDIObjects

Lionel Drevon
Adeli http://www.adeli.fr
618 Av. Gal de Gaulle Tel 04 78 66 11 85
69760 Limonest Fax 04 78 66 04 33

If you happen to have a copy, I would suggest that you roll back to an earlier version of GTK+ for Windows. The December 2000 release of the tool kit gave me a few problems when I tried to install it on my software development system (which includes a whole bunch of other stuff for a scary testing environment, so this may not be the case for everybody) I couldn't get it to work, or even run GIMP for Windows. I haven't had the time to try and see what exactly was the problem, although this may also have an impact with Lazarus as well.

+ From: Mattias Gaertner
+
+ TGraphic and TPicture is ok. But the TBitmap and TPixmap need
+ some work. TBitmap needs LoadFromStream and SaveToStream code.
+ My idea is to read and write window bitmaps, but to work with
+ an interface dependent format in memory. For the gtk the
+ working/in memory format should be GDKPixmap.
+ Thus we need two procedures to convert bitmaps to GDKPixmap and back. +
+ What do you think?

IMO we should not work with platform dependent bitmaps. There should be no platform code in the LCL. (Where it is not it is only for temporary usage).

Why not with the bitmapbits only with a header with some info. (I know this looks like a bitmap or a pixmap structure). In any case we have to convert the info from and to a (Win)Bitmap or a (X)Pixmap (or a (X)Image).

I didn't follow the recent developments on the Image, but as far as I can remember, Delphi doesn't store the actual bitmap, so why do we ?

Marc

Mattias Gaertner �����:

I think, pixmap may be quite good solution as it is text file. But... I don't know its structure enough to provide conversion (even worse than bmp sturcture). As for streaming TBitmap, my idea was to leave all as is: bitmap (at that time it was WinBMP) is bitmap,
pixmap is pixmap (why should we do such conversion without any reason?). Then (may be even with operator overloading) we can provide conversion procedures.

The problem is (status on 7.03.01) that TPicture isn't usefull. Besides, somebody added
fmFileDenyWrite in graphic.inc, but in FPC it is not supported (see FPC 1.0.5 on your site). Where is TImage component? It must be in extctrls. My images unit, course, can't work with modified TPicture (but it can be corrected, I think).
May be, it is reasonable to make patches system, as, for example, for wine (not daily snapshot, it is too often, may be, once a week or two). Somebody (for example, me) can't use cvs (as for me, I have internet access on University computer, while FPC is on my home computer, where it is neither Internet via modem, nor even telephone).
And, (may be, it is not up to date), we must have quick painting procedure, may be, canvas.pixels.

Post-graduate Vasily

Is there any possiblity of having a windose version of the daily builds. I think it's important to have Linux and Windows being developed in tandom, otherwise it will become lopsided (like it is now).

JMHO

Chris Bruner

Hi

some changes:

+ Turned on longstrings
For now in some units it is turned on, and
will for all in future. It is needed for some
StringList based operations (TMemo)

+ modified memotest to add lines
Assign strings to a memo worked, however adding
more that 255 chars didn't. I added this to check

+ Changed scrollbar code in the widget for TMemo
Now it has also a horizontal scrollbar

* New makefiles
Changes some building steps. Now we can distribute LCL-units / GTK-units / x-units, where the widget set to use is determened at compile time of any app.

Marc