PureBasic 3.93 beta 3 for Windows released
The problem was the additonal japbe-constants. I have correct this.
please only download the complete file, when the uiu doesn't work:
http://gpihome.de/purebasic/jaPBe/
please only download the complete file, when the uiu doesn't work:
http://gpihome.de/purebasic/jaPBe/
thank's , uiu and japbe work fineGPI wrote:The problem was the additonal japbe-constants. I have correct this.
please only download the complete file, when the uiu doesn't work:
http://gpihome.de/purebasic/jaPBe/

Please correct my english
http://purebasic.developpez.com/
http://purebasic.developpez.com/
Ahh, it looks like it is aXend's COMLIB that is causing me the problems..
I'll see if he can recompile it or something.. Does he just need to use the latest tailbite or wait for a future version that supports the soon-to-be 3.93 ?
I'll see if he can recompile it or something.. Does he just need to use the latest tailbite or wait for a future version that supports the soon-to-be 3.93 ?
-Mitchell
Check out kBilling for all your billing software needs!
http://www.k-billing.com
Code Signing / Authenticode Certificates (Get rid of those Unknown Publisher warnings!)
http://codesigning.ksoftware.net
Check out kBilling for all your billing software needs!
http://www.k-billing.com
Code Signing / Authenticode Certificates (Get rid of those Unknown Publisher warnings!)
http://codesigning.ksoftware.net
And all this time I thought it's prohibited to use pb's lib functions in dll's for other compilers... :roll:Fred wrote:Nothing change here, it allows you to use your dll in VC++ (or any other compilers) for your own projects easily.fsw wrote:Does that mean that now DLL's generated by PureBasic can OFFICIALLY be used with applications programmed with other compilers
> all this time I thought it's prohibited to use pb's lib functions in dll's for other compilers... :roll:
It depends on how you're using the PureBasic lib functions. See Num3's
explanation here: viewtopic.php?t=8895
In other words, you can't just "wrap" the PureBasic functions in the DLL...
You need to code your own actual routines, or use the Win32 API instead.
It depends on how you're using the PureBasic lib functions. See Num3's
explanation here: viewtopic.php?t=8895
In other words, you can't just "wrap" the PureBasic functions in the DLL...
You need to code your own actual routines, or use the Win32 API instead.
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.
@pb: Thanks for pointing me to the right topic.
The newest help file says (under 'Terms And Conditions'):
Because of OOP's and EVENT-DRIVEN nature it's not a wrapper of pb's gui commands, but rather a big pile of code.
But now I'm also a FreeBASIC user - and would like to use it with this compiler too.
And maybe when my OOP-GUI is grown up (still some inconsistencies and quirks in it...) make it usable for somebody else...
The newest help file says (under 'Terms And Conditions'):
Some time ago I coded an EVENT-DRIVEN OOP-GUI that I use for my own projects.All components, libraries, and binaries are copyrighted by Fantaisie Software. The PureBasic license explicitly forbids the creation of DLLs whose primary function is to serve as a 'wrapper' for PureBasic functions.
Because of OOP's and EVENT-DRIVEN nature it's not a wrapper of pb's gui commands, but rather a big pile of code.
But now I'm also a FreeBASIC user - and would like to use it with this compiler too.
And maybe when my OOP-GUI is grown up (still some inconsistencies and quirks in it...) make it usable for somebody else...
-
- Enthusiast
- Posts: 202
- Joined: Sun Apr 27, 2003 4:44 am
- Location: Michigan, USA
- Contact:
fsw you bring up a good point that has buged users for a while. Why is this limitation in PureBasic. Just imagine if Microsoft had that in there API Fred couldn't even make his compiler. Programmers wrap libraries all the time. The C runtime for example is probably the most used in wrappers for other languages. Imagine how unpopular C would be if it had such odd restrictions.fsw wrote:@pb: Thanks for pointing me to the right topic.
The newest help file says (under 'Terms And Conditions'):Some time ago I coded an EVENT-DRIVEN OOP-GUI that I use for my own projects.All components, libraries, and binaries are copyrighted by Fantaisie Software. The PureBasic license explicitly forbids the creation of DLLs whose primary function is to serve as a 'wrapper' for PureBasic functions.
Because of OOP's and EVENT-DRIVEN nature it's not a wrapper of pb's gui commands, but rather a big pile of code.
But now I'm also a FreeBASIC user - and would like to use it with this compiler too.
And maybe when my OOP-GUI is grown up (still some inconsistencies and quirks in it...) make it usable for somebody else...
I know the bid deal about a whole other language being built from PureBasic but instead of be offened just realize that it is a compliment and a promotion of your product being so good. These statements of limitation just scare users away and I know that Fred and company just want to protect there intelectual property but then there should be A LOT more detail on what this clause means to the users.
-Ryan
RJP Computing
Ubuntu 8.10/WinXP, AMD Athlon 64 3000+, 1000MB RAM, AC 97 Audio, nVidia GeForce 7600GT 512MB
RJP Computing
Ubuntu 8.10/WinXP, AMD Athlon 64 3000+, 1000MB RAM, AC 97 Audio, nVidia GeForce 7600GT 512MB
RJP, I don't think it unreasonable to forbid wrapping of PB commands. Otherwise other less honest BASIC authors might just wrap up PB commands and pass them off as their own.
I can't imagine a time when you need a wrapper DLL around PB commands except for the explicit purpose of ripping PB commands off to pass as "native" for some other language. PB doesn't have anything all that special that isn't offered through the win API or through any other language worth a salt. PB's value is in it's ability to be used as a single language to develop small, fast applications.
Having said that, there is no way to prevent this from happening so only honest users are going to abide by the license.
I can't imagine a time when you need a wrapper DLL around PB commands except for the explicit purpose of ripping PB commands off to pass as "native" for some other language. PB doesn't have anything all that special that isn't offered through the win API or through any other language worth a salt. PB's value is in it's ability to be used as a single language to develop small, fast applications.
Having said that, there is no way to prevent this from happening so only honest users are going to abide by the license.
-Mitchell
Check out kBilling for all your billing software needs!
http://www.k-billing.com
Code Signing / Authenticode Certificates (Get rid of those Unknown Publisher warnings!)
http://codesigning.ksoftware.net
Check out kBilling for all your billing software needs!
http://www.k-billing.com
Code Signing / Authenticode Certificates (Get rid of those Unknown Publisher warnings!)
http://codesigning.ksoftware.net