PureBasic Forums - English

As I did not find RS 232 Communication function in PB, I wrote a library (4Ko). Included in the Zip file, the library help file, an installation software and a sample PB source to demonstrate the library functions.

I also try to upload it to PB resources site.

To download the Zip file clic here http://perso.wanadoo.fr/marc.vitry/purebasic.htm

Well done Marc

Great tool !
I'l have a test tomorow.
Just a thought: why did you limit the speed to 19200 b ?
Some can goes upper

Thank's again !

In the demonstration software the maximum speed is 19200 but can be change in the source. The Comopen function also accept 57600 and 115200 Bds.

Regards

That was what i thought too !

Thank's.

Looks very nice.. Thanks for this lib

well done

Looks excellent, complete and ready to use with help file.

But this raises a question for me.

Should this be integrated into PureBasic with new PureBasic commands and the Help info transferred into PureBasic Help? Or should this be a standard addition to the UserLibraries folder for future PureBasic downloads?

Marc would you be happy to see this happen?

We could all use a variety of different libraries from various sources, for example there are several options for RS232. However, there is a lot to be said for incorporating the best solutions into the standard package. That way the whole PureBasic user base is available to identify possible bugs and incompatibilities and any user who finds problems can expect other users to be able to help.

I guess this is something of a difficult issue, some people may not want to see their hard efforts incorporated as an unidentifiable part of something larger. But for most users this would probably be the best result.

I agree and it's only up to the library maker choice. This what it happens with the very good 'OnError' lib, which is coded by Rings and PureFan and which is now part of the PureBasic package, thanks to them.

But this lead to several problems which aren't so obvious. Until now, I wrote almost all the commands which means than I know the code and know how to fix it if something bad happen. Now imagine I package several big libs and the users behind them leave. Once a bug rise, I will have to spend a great amount of time only to understand how the code works. Understand C code is relatively easy when it's well written, but ASM one is another matter. The other topic is the cross compatibily: I have to be able to do it for any other plateform that PB support, and when I gain time by getting it finished on one plateform, I lost it on the other one .

Anyway, I'm not against this fact, I just want to clarify the things. I believe in the plugin concept, and actually you can do an user lib which perfectly integrate the PB environment (same help, F1 on keyword call help etc...), so...

I would like to see only libs which are definitly coded by the PB Team. Couse only here we can be sure to get the support and the knowledge of the library a registred user should be able to get.
Also the benefits and credits belongs longer to the original author - and thats mostly all what he is getting for his work.

Respect to the PB Team and all users who supports them. (especially Berico, Siggi, Timo, Danielo, Fred)

Anyway, a good community here! nice to see!

Cheers
Mike

I'm totaly agree with Fred. User libraries concept is good for PB and for the all users.

Message: Bravo à toute l'équipe de PB.

Regards.

Marc wrote:I'm totaly agree with Fred. User libraries concept is good for PB and for the all users.

Message: Bravo à toute l'équipe de PB.

Regards.

Well Fred, it's almost 7 month that I told you my opinion about this matter.

The User Lib stuff is really good, but YOU never know how good a user lib is coded, that's for sure ( in C or ASM ).
So if the user lib coder leaves the community and something is wrong with the lib....
More throuble YOU will have, if you incorporate a user lib in the PureBasic package and something is wrong with it.

And finally as you can see, there are users, that like to have only libs coded by the PureBasic Team. Not a good solution, because the creation of new libs would be minimal... and this would NOT attract new users.
( and if somebody doesn't like a lib, because it's not coded by Fred - don't use it! )


My opinion on this is to make it possible that PureBasic not only can make Executables (EXE) and Dynamic Libraries (DLL) BUT ALSO Static Libraries (OBJ).
This would enable to have user libs made with PureBasic itself, the assembler source file would be fully commented (because the PureBasic code would be there in a comment line - in addition to normal comments).

So if YOU like to incorporate a user lib in the PureBasic Package, you would get the whole source, and it would be an easy task for YOU to find bugs.

Think about it, PureLIBs written in PureBasic itself would kick a$$
And attract new users as well

fsw wrote:Think about it, PureLIBs written in PureBasic itself would kick a$$ :idea:
And attract new users as well :wink:

What about this (semi-alternative): the user codes their own procedures as normal, and sticks them in an include file. Fred provides some way for them to have "init" and "shutdown" procedures which automatically get called at program startup and exit. At some point, Fred was going to implement the removal of unused code.

Instant library without the hassle of libraries. Kind of :)

Keep in mind than the libraries are the core of every programs written in PureBasic. And even if the generated PureBasic code is good, it's far to match an hand optimized asm one, that's why I'm a bit restrictive while doing lib in PB. But why not, I could consider it.

Fred wrote: But why not, I could consider it.

YES PLEEEEEEEEAAAAASSSSEEE

Fred wrote:Keep in mind than the libraries are the core of every programs written in PureBasic. And even if the generated PureBasic code is good, it's far to match an hand optimized asm one, that's why I'm a bit restrictive while doing lib in PB.

I can fully grasp your thoughts and understand what you are saying.

But it's the same with DLL's.
You never know how good it's coded.

Example: For now I code some functions in a dll and call the dll functions, what works well, but I have always to copy the dll to the exe to keep it going (or copy the dll to the system folder - arghh).

If PureBasic could make DLL's OR OBJ's - it's exactly the same code.
So hand optimation is never done. Not as DLL and not as OBJ.
And if the user can understand the asm code and optimize it - that's excellent for DLL's and OBJ's.