Two days left to get EZGUI 5.0 Pro for only $26.95

[Chris Boss]

Just 2 days left to get this special offer!

The web page says $49, but if you act now before the end of July 31, 2017 , when you go to the order page it will show another discount of 45% off which will make it just $26.95.

My web page where you can select to order: http://cwsof.com/softdev/purchase.html

Here is a direct link to the BMT-Micro order page so you won't be confused: https://secure.bmtmicro.com/servlets...DUCTID=7270033

[JR Spikowski]

Hi Chris,

Is EZGUI now a hobby or are you still trying to make a living off it? The price has dropped so low, why bother?

Very interesting. Maybe in next few days if I can afford it, might pick up a copy. Looks very powerful.

Not a good sign.

[Chris Boss]

The price reflects the market, not the product. Until things get up to speed at Powerbasic, the market for third party products will be 'slim pickings".

That said, EZGUI has never been nor hopefully will ever be a "hobby" to me. I have a strong customer base to support and I am looking into alternate markets.

Just take a look at my forums. Tech support is strong and EZGUI users are still developing apps with it.

One direction I am considering is in developing online training for EZGUI (paid courses). A number of users are making a living off of developing apps using EZGUI.

Now while the low price is dependent upon current markets right now, this does not reflect the true value of the product. EZGUI is worth every penny of even is normal price of $249.

No addon for Powerbasic currently has the rich and extensive feature set that EZGUI does. It is not simply a visual designer, but is a GUI framework. I have yet to see as powerful a GUI framework for Windows with as small a footprint as EZGUI.

I have also made some profit off of licensing a full source code version of the EZGUI runtimes or the Visual Designer to a few. That is not though a normally publicly available product, since it requires signing an NDA first and it is not cheap by any means (in the 4 digit range).

So the problem is not with EZGUI, but with the current Powerbasic market. EZGUI will continue to be supported and hopefully new markets will emerge in the future.

I am simply "hanging" onto the Powerbasic market in hopes it will improve in the future, while most third party developers have moved on to other development tools.

[JR Spikowski]

Thanks Chris for the update. A way to see more business for EZGUI is create a C .h include file. You should also offer a free / trial version that promotes an upgrade.

[Chris Boss]

I have to do a significant conversion of many EZGUI functions which pass string parameters before it can be used with other languages. Powerbasic's use of OLE for strings, while better IMO, it also makes use with non-PB languages difficult since most do not support directly OLE type string data types. With a command set of nearly a 1000 GUI commands and most passing strings, this means a lot of work to make it compatible with other languages.

[JR Spikowski]

I can call functions with OLE string arguments from Script BASIC using the DLLC extension module. It's sort of a FFI interface on steroids. Do you offer a version of EZGUI I could give it a try with. I'm sure OxygenBasic would have no problem calling EZGUI functions.

[Patrice Terrier]

Chris

I never understood why you where using strings for most of your parameters.
Obviously there is a huge amount of work if you want to use your LIB with another language.

For a SDK programmer C programming style is not that hard to learn, and it is your only salvation solution if you want to stay in this buisiness.
Don't make twice the same mistake, avoid like the plague all exotic flavor of BASIC.

[JR Spikowski]

I have to agree with Patrice that you need to expand your reach to stay in business. Hope isn't a strategy.

[Raymond Leech]

Chris, couldn't you do an ASCIIZ wrapper interface to the string routines which would quickly get you most of the way home? I have one library in my system that must be called from two languages. Each routines that takes a bstr parm has a matching Routinez equivalent which does the conversion. The runtime difference is hardly noticeable. Wouldn't that be an easy way to bridge the gap while you do the longer re-engineering project?