JPG IMG controls... (Why is that not here?)

[ISAWHIM]

I can understand the use of BMP, since it is a simple RAW format, commonly used for icons and small images.

However, I can not understand why JPG has not been added yet. The code is free to use for "Viewing", and I think it is now free to use for "Saving", just like GIF.

This is a major file-size saver. Not to mention, it allows online files to be included in the program. (Yes, you can put BMP online also, but sending a BMP, due to size, is a waste of bandwidth.)

For the UI, there should be a standard IMG control. IMGBMP, IMGJPG, IMGGIF, each with the ability to be... scaled within dimensions, stretched to dimensions, fixed size, clickable (additional DOWN image), selectable (additional SELECTED image), and maskable (additional color-mask image, on color of 2-256 or full color, possibly with future ability for full 256 shade masking.)

I would suggest PNG, but there is no advantage to that horrible format. (Not file-size wise, except over BMP. Since PNG is just layers of BMP's, without a real standard, it is complex to handle them correctly when they use multiple layers. But that would make a great future toy.)

[ErosOlmi]

Again you are right but to manage JPG and other file formats you need additional libraries not available in all OS.

GDI+ can be used but not available for Win9x systems so users have to download from Microsoft.
We will try to develop something for this as it seems a requests made by many. But only when we will move to thinBasic version 2.x (in few weeks I think)

Eros

[kryton9]

I think with GDI available in so many computers now and it is downloadable if not, I agree, it would be great to have png support at least since this also makes very small file sizes but also can store transparency information.

[ISAWHIM]

I know it is available as an API, like BitBlt... (Though I forget which dll it is inside of.)

Was part of MSIE 5 core files, which are still inside win 95, 98, xp...

I need to break out my old API viewer that I had for VB. (Shows TONS of neat hidden API commands. Most were faster than VB, thus, the strong use of them in VB as a normal method. Like the TIMER function API and the SLEEP.)

Also note... The links you have in the online HELP... no longer point to the correct pages in the MSDN library. Might want to make them point to a general MSDN search, with specific key-words, as opposed to pointing to a page that Microsoft keeps moving. They do that on purpose, for multiple spider-bot logs and relevance, using the same data.

I am excited to know that there will be a version 2...

My request for that... Fix-up some of the programming inconsistency for that release, before you release it. (Since it will be a new version, it is justifiable that certain elements change.)

EG...

Like the "Font" thing I just read...
Font_draw and DRAWFONT... (Or whatever...)

Both are the same function, one with more functionality. Both should be the same command.
Font_Draw (Size, Style)
or
Font_Draw (Size, Style, other1, other2, other3, other4)

There was another thing that bugged me... (Pun intended)
Some_Function somestuff, somestuff, somestuff
Some_Function (somestuff, somestuff, somestuff)
Some_Function, somestuff, somestuff, somestuff

We need to "Remember" which functions call for which method... That is bad... (Difficult to master, and just annoying when you get random popups related to format.

Use a standard...

Some_Function (somestuff, somestuff, somestuff)

That is all you need. Simple, can be reverse played, for those functions which normally expect "Some_Function somestuff", or "Some_Function, somestuff".

The specific area where I see this happen, is on the controls, like the LISTBOX... where that control has separate "Other" functions.

There are also some ODD control attributes...

COMBOBOX "Demands" a height setting, but height is irrelevant and ignored.

BUTTONS have a height setting which is the INNER HEIGHT, which should be "Adjusted" from the height we input as the height for that control. (The control is +6 pixels taller than the value we put inside. Thus, our number we use, should be X-6 or 7 if the value is less than 7. That stops an error from happening on that control from feeding it a negative number.)

EG, If we say it should be 20 pixels tall, it should be as tall as all other items that are 20 pixels tall. Not 26 pixels tall. That makes us have to "Adjust" our values for every button control. (Where we want ROW-X to be 20 pixels, and a button is on ROW-X, the height for that control has to be ROW_HEIGHT -6, while all other items are ROW_HEIGHT.)

OK, I am a little off topic... LOL