PureBasic Forums - English

Hallo,

I hope I haven't missed these in the docs:

1) All gadgets need focus events.

2) The Editor Gadget needs a function to get the length of the text.

3) The Editor Gadget needs a function to get the number of lines.

4) Tab Order should have controls to allow the programm to modify it and include/exclude gadgets from the tab order.

5) I would like to see strings with more than 64k length (LongStrings ?).

6) The docs ought to include a list of all standard constants etc.

Finally two questions:

1) How many bytes can the editor gadget handle?

2) How many lines of text can the editor gadget handle?

Greetings,

toby

1) How many bytes can the editor gadget handle?

2) How many lines of text can the editor gadget handle?

Information like this really belongs in the docs.

eths wrote:

1) How many bytes can the editor gadget handle?

2) How many lines of text can the editor gadget handle?

Information like this really belongs in the docs.

I'm not sure, but I think this is limited by windows, and not by PB..
(someone should verify if I'm right.)

I think this is limited by windows

And what about Linux?

1) All gadgets need focus events.

Agreed, it'd be nice for all gadgets to have focus events accessible easily. String gadgets do from straight PB, others it's a fairly easy windows callback. Let me know if you want the code (it's all over the forum I'm sure)

2) The Editor Gadget needs a function to get the length of the text.

len(getgadgettext(#Editor)) and I'm sure there is a message you can send to the gadget. Check MSDN or search the forum to make sure..

4) Tab Order should have controls to allow the programm to modify it and include/exclude gadgets from the tab order.

Yea, tab orders are a pain in the butt.

5) I would like to see strings with more than 64k length (LongStrings ?).

Search the forum for string buffer as it's possible (and easy) to increase the buffer's size. This is already on every to-do list since PB 2.0 though.

6) The docs ought to include a list of all standard constants etc.

It does include the PB related ones in the relative library documentation. There are tens of thousands of windows constants - but there is a resident file floating around with all of them. Check the resources site or search the forum for a link.

1) How many bytes can the editor gadget handle?

You'll have trouble dealing with more than 63999 bytes of data due to the fixed length string limitation.

2) How many lines of text can the editor gadget handle?

If there was a limitation (and there might be) it'd be a limitation of the total amount of data, not number of lines.

Agreed, it'd be nice for all gadgets to have focus events accessible easily. String gadgets do from straight PB, others it's a fairly easy windows callback. Let me know if you want the code (it's all over the forum I'm sure)

For Windows this may be true (yes, I'ld like to have the code), but what about Linux? It would nice could if PB would handle this.

len(getgadgettext(#Editor)) and I'm sure there is a message you can send to the gadget. Check MSDN or search the forum to make sure..

Linux? Text longer than 64k?

The point is, stuff like should be easily portable, i.e. the same code should work for both. I would not expect this from the web gadget, but the editor gadget is, according to the docs, supported for Linux and Windows. MSDN is useless for Linux.

It does include the PB related ones in the relative library documentation.

I might be stupid and/or blind, but I can not find such a list. For example where is #TRUE documented? Answer: Well hidden in AdvancedGadgetEvents.

You'll have trouble dealing with more than 63999 bytes of data due to the fixed length string limitation.

As long as each line is less than 64k then this ought not to be a problem. However a clean method to find out how many lines need to be read is necessary.

Linux? Text longer than 64k?

Len(GetGadgetText(#Gadget)) should work on Linux too AFAIK. Still limited to 64k strings.

I might be stupid and/or blind, but I can not find such a list. For example where is #TRUE documented? Answer: Well hidden in AdvancedGadgetEvents.

Right, the docs are spread throughout the documentation. I'm not sure that there is one definitive list with every constant. Start one!

As long as each line is less than 64k then this ought not to be a problem. However a clean method to find out how many lines need to be read is necessary.

Personally I don't see this as a need in the core language, but that's just my opinion. You can GetGadgetText and count the CFLF characters now.

BTW, in the past several people have gotten upset when others reply to their feature requests. Don't! I'm not arguing about the validity of any of your requests, only trying to give you some hints to get you doing some of this stuff with the current functionality.

Personally I don't see this as a need in the core language, but that's just my opinion.

I'm not sure that I agree, but I do see your point.

You can GetGadgetText and count the CFLF characters now.

True - but somehow it just feels messy and slow. I would have thought that the gadget has line counter built in, and exposing this to us lowly types would be easy and fast in run time.

Len(GetGadgetText(#Gadget)) should work on Linux too AFAIK. Still limited to 64k strings.

Which, for a bit of software I am writing, is a bummer. Again this strikes me as messy and slow. The Gadget must know how much data it has, so making this number avaidable to the programmer strikes me as sensible.

Thinking about gadgets, I think it could make good sense for all gadgets to have certian common functions and properties, eg something along the lines of GetFocus, LooseFocus, IsFocused, DataLength, OnChange and so on ... These should be identical (as far as possible) for Windows, Linux and/or Amiga.

Are you developing on Linux? If not I'll dig out the message to send to the gadget to get the amount of data (and probably the number of lines).. It's a Windows only thing, though...

Are you developing on Linux?

Up to now no, but as soon as the programm reaches a healthy level, I will
be porting to Linux. In the long run it should run on Windows and Linux.