Author Topic: PowerBASIC  (Read 45590 times)

0 Members and 3 Guests are viewing this topic.

JRS

  • Guest
Re: PowerBASIC
« Reply #75 on: March 03, 2018, 09:18:49 PM »
Chris,

If you offer EZGUI as a DLL, why can't it be called from OxygenBasic? What makes it so special to PowerBASIC?

Do you have a eval version of the EZGUI DLL we can play with?

Karen Zibowski

  • Guest
Re: PowerBASIC
« Reply #76 on: March 04, 2018, 06:06:07 AM »
Chris
Perhaps you should make a dialog visual designer for OxygenBasic, since PowerBasic has already died.

Aurel

  • Guest
Re: PowerBASIC
« Reply #77 on: March 04, 2018, 07:08:20 AM »
I really don't know why u PB people call everything DIALOG
It is called VISUAL FORM DESIGNER..
In win api gui programming there are two types of standard gui forms and they are
WINDOW and DIALOG

Raymond Leech

  • Guest
Re: PowerBASIC
« Reply #78 on: March 04, 2018, 08:33:39 AM »
I'm new 'round here, so hello everyone!

We don't really use any forms designers to their full potential, mainly because none of them do what we need -- or more truthfully, what _I_ want :). What we do use is really for pixel placement and we manually code the rest.

My utopian view of a forms designer would simply be that, a forms _designer_. Canvas, window/dialog, common objects (fields, selects, buttons, checkboxes).

Where a designer would get my attention was if after the design phase, it gave me the option to pick the emitter, which would probably match a DLL name.

Now that you've separated the designer from the emitter, I could care less what you wrote your designer in, keep it in PB32 for all I care. If you use  standard calls, no one cares what the actual emitter is written in either (do what makes you happy). Its simply a standard DLL.

OOTB, Chris might provide a PBEZGUI dll that generated all the code as he sees fit in PB to call his EZGui DLLs. He might just as well provide a CEZGUI which generated C WinAPI Code using null-terminated strings instead of BSTRs. John likes IUP, so maybe he writes his own DLL that generates ScriptBasic w/ IUP routines. I might be doing a web project so I create a DLL that emits HTML/CSS/JS forms and nothing for the back end.

To use EZGui as an example. During the generation process, ChrisB might invoke individual routines in the emitter like gen_canvas, gen_window, gen_object, gen_field... He might also call a single routine 'generate' which had all the object definions in one big bucket and the DLL author breaks it down.

Now, Paul Squires Firefly had a novel way to write custom code at all kinds of events on objects. If you took Firefly (similar to the old VB designer) as the example, every event would have separate code block per emitter. For example Event:'On Focus' might allow you to pick from the list of registered emmitters (Paul's case PBWinAPI or FBWinAPI) and enter your code in the appropriate 'final' language (PowerBasic WinAPI, PB DDT, FreeBasic, Oxygen, IUP, JavaScript, whatever) as appropriate.

Now to me, that's a designer I'd have to have. OOTB it wouldn't do what I needed/wanted, but it probably would after I wrote my own emitter.

That's just my opinions on a designer. YMMV

Karen Zibowski

  • Guest
Re: PowerBASIC
« Reply #79 on: March 04, 2018, 10:56:32 AM »
Raymond

A visual designer like Firefly and Ezgui will save programmer's time to build a dialog
and helps O2 beginners like us to learn coding in O2.   It is a rapid way of generating codes
it is the modern way.  It will attract more coders to come to O2

Anyway, with zero development in FreeBasic and PowerBasic, these languages are destined
to go extinct.  Only O2 has a viable forward looking platform.  We beginners would love to have
something like Ezgui to do rapid program code generation for O2. 

I believe it is pointless to stick to PowerBasic when there is no progress in their compiler development,
 either jump ship or die with the sinking ship!   64bits is here to stay and 32bits will fade away

Karen Zibowski

  • Guest
Re: PowerBASIC
« Reply #80 on: March 04, 2018, 11:05:36 AM »
Sorry Aurel, 

We PB coders always talk in Dialog ways ( perhaps due to the lack of Dialogs with other language programmers)
 :D

Yes, we would prefer to have a Visual Designer so as to ease our beginners' programming in O2
perhaps you could come out with something like this? 

Aurel

  • Guest
Re: PowerBASIC
« Reply #81 on: March 04, 2018, 11:18:15 AM »
Sorry to you
but what kind of programmers start with Visual Designer?
Are you sure that you will learn o2 better with GUI builder...
I think no...
I do programs in PureBasic and never use designer  built in editor why?
simply because that is slow for me....
I underst to use of designer if you build GUI program with 200 controls and more
but with few controls ...hmmm

for 64 bit ,,, well 32 bit programs are still dominant on Windows and used by many developers.
by the way u use 32 bit with Power basic and now you need 64 bit...
I understand that 64 bit is next step but real advantage is only in amount of memory..right?

Charles Pegge

  • Guest
Re: PowerBASIC
« Reply #82 on: March 04, 2018, 12:26:52 PM »
Hello Ray,

Welcome to our forum.

I have never seriously attempted to use a GUI designer, though I did look at Firefly many years ago. To me, programs are like lego - to be dismantled for their desirable components, which might be made to do something interesting when rearranged. :)

But I would like to understand more about the GUI design process, - program design from the outside in, so to speak.

Mike Lobanovsky

  • Guest
Re: PowerBASIC
« Reply #83 on: March 04, 2018, 01:11:40 PM »
WOW! :D

@Raymond:

Quote
Paul Squires Firefly had a novel way...

Nothing novel really. VB6 IDE was and still is an ultimate example of an event driven RAD tool.

PB Inc. had to compete with MS Corp. for paying customers (and that's dead frost by definition, actually) so anything likewise "event-driven" was not, uhm, kosher. But since there is simply no alternative way to design a competitive visual, er, designer, Bob just preferred to keep himself aloof. If he really saw any other way to get out of this stalemate, both Paul and Chris would have been eliminated from the PB scene one way or another long before their respective projects took off.

That's why my eyes just bleed every time I look into PB's stock tool set.

Thanks for joining our discussion so substantively and welcome to the ranks! :)


@Chris:

Thank you very much for the feedback and welcome to the forum! In fact, your "CV" generated a strong dejavu I was reading my own. :)

So, EZGUI is a visual designer/skinning engine framework written in PB for use in PowerBASIC programs? Does it emit any actual PB code? If yes then why not make its code emitter extremely limited, or partial, or selective (or disable it altogether in the last resort) and have a demo version to let customers evaluate the actual look and feel of your product under "field conditions"? If that's feasible for you in principle then I would second John's request to let us have something to "play" with. I think we will all need some time to think things over again and see if somebody else has anything to suggest or offer.

Re. STL, that's a very primitive 3D CAD data exchange format. Alias Wavefront OBJ format is a universal, albeit rather basic (pun not intended), vendor-insensitive format to exchange creative content between different 3D SW packages. Every 3D modeler supports (to a certain extent) at least an OBJ format exporter as a limited alternative to its own proprietary output.

If I knew more about the actual code you're using to draw your STL data in your OpenGL canvas, I could probably help you out with getting a basic (this time, in both senses of the word) OBJ importer up and running to make your OpenGL feature actually useful to people. And no, I am not seeking compensation or employment or something in exchange. :)


@Aurel:

No, nothing special. FBSL currently has a very basic form designer (FMFD) written in FBSL and built around Public Domain code freely available on the net. (see picture 1)

It's a little buggy as was its prototype, but usable. I lost interest in fixing someone else's code when John the then "BASIC land collector" backed by a couple of BCX eggheads attacked me with accusations of abusing sacred GNU GPL property. Licensing legalities were not his strongest point at those times and now he knows better, but sort of an aftertaste remained, and I dropped the project there and then.

I had another project in mind called FBSL Script Factory, FSF. (see picture 2) But I also dropped it because
i) I had to write it in OOP-ed FBSL (the FSF code highlighter object required concurrent instantiation in multiple code windows) and I don't like OOP in my own code; and
ii) I had been planning to use portions of FMFD code in it but later felt kinda squeamish to.

So I concentrated on Eclecta, FBSL stock code highlighting editor written in FBSL and designed in its own environment from ground up. (see picture 3)

It has a typical multiple-document tabbed editor interface, is user configurable, is capable of highlighting and formatting properly three different FBSL language syntaxes simultaneously, and provides easy access to a number of FBSL own and 3rd party tools I used to find helpful in my day to day dev work.

-- Yes, FBSL has two skinning engines and can unify the looks of both FBSL process windows and 3rd party windows on the fly in real time.

-- Yes, FBSL can skin W'10 kiddies-first-gadget windows with Win'7-like adjustable semi-transparent colorful blurrable decorations.

-- No, FBSL cannot skin the console window. Nobody can.

-- No, FBSL v3.5 RC3 or Stable will never be available for download. I lost interest in native or WoW64 32-bit compiler development.

-- Yes, FBSL v4.0 might appear but if and only if:

i) Drake Software would not come up with 64-bit PB vXX.X by the end of the 2-year period that's required for a sole indie developer to release at least a beta version of competitive product. This period expires this year; AND (no C-style short circuiting here, both conditions must be met as per BASIC tradition)
ii) Charles refuses to lead the project under the Oxygen Basic banners.

-- No, I am not planning to R.I.P. before the deadline or in the foreseeable future.


Dixi.

[attachment deleted by admin]
« Last Edit: March 04, 2018, 01:22:35 PM by Mike Lobanovsky »

Aurel

  • Guest
Re: PowerBASIC
« Reply #84 on: March 04, 2018, 02:03:24 PM »
Hey Mike
new Eclecta really looking nice!

Raymond Leech

  • Guest
Re: PowerBASIC
« Reply #85 on: March 04, 2018, 05:21:20 PM »
PB Inc. had to compete with MS Corp. for paying customers

I'm sure Bob 'felt' that way then, but wayback then the playing field was much different. The number of quality 3rd party designers was, shall we say, lacking! E.g., anyone remember the initial release of PowerBuilder? Oh, the memories!

But with the number of descent designers today, to me it doesn't make sense for the compiler writer to focus on designers and DDT-like language extensions.

JRS

  • Guest
Re: PowerBASIC
« Reply #86 on: March 04, 2018, 05:30:06 PM »
I would rather have core BASIC functionality and useful documentation then a GUI extension taking precidence.
« Last Edit: March 04, 2018, 06:38:00 PM by John »

Raymond Leech

  • Guest
Re: PowerBASIC
« Reply #87 on: March 04, 2018, 05:46:46 PM »
Anyway, with zero development in FreeBasic and PowerBasic, these languages are destined
to go extinct.  ...  either jump ship or die with the sinking ship!

We still get at least three requests a year to migrate some 'mission critical' app from VB6, which hasn't had an update since 1998! Using that math, there could be PB apps running beyond 2032 :-o 

In business, the world rarely ends because the compiler wasn't updated in 3 years.

So does that mean you should start new projects in PB in 2028? No.   Does that mean we should throw away 10+ years of work because Drake didn't provide a new compiler by Dec 31? Also no.

JRS

  • Guest
Re: PowerBASIC
« Reply #88 on: March 04, 2018, 06:43:29 PM »
Quote
Does that mean we should throw away 10+ years of work ...

The problem with compilers frozen in time is Microsoft at any moment could deprecate a function or API and your software becomes unusable in current OS versions.

Drake would be foolish investing any money in PowerBASIC. There is no market for a 32 BASIC compiler with deep roots to its DOS predecessor. They are moving to the cloud and a web browser interface with their tax software. They are already selling subscriptions to it.
« Last Edit: March 04, 2018, 08:01:30 PM by John »

Mike Lobanovsky

  • Guest
Re: PowerBASIC
« Reply #89 on: March 04, 2018, 08:11:37 PM »
I would rather have core BASIC functionality and useful documentation then a GUI extension taking precidence.

What a linuxoid calls an "extension" is "core functionality" for a windozer. We couldn't care less also for what sudo or kernel are. That's why MS practically owns the business market while Linux is within the limits of statistical error together with its rudimentary and multiply incompatible "GUI extensions".

Quote
... foolish investing any money in PowerBASIC ...

Again, what you're calling "foolish investment" is effectively called "investment protection expenses" covering a much more substantial venture on cloud technology. They don't want to arm anybody with an industrial grade weapon of competitive efficiency but alternative nature.

Quote from: Raymond
... Does that mean we should throw away 10+ years of work because Drake didn't provide a new compiler by Dec 31?

I am not advocating an alternative to 32-bit PB. You can still buy it from Drake (no charity any more though). I am advocating an alternative 64-bit implementation semantically and functionally compatible with, if not equal to, the 32-bit prototype. Superior functionality can wait. People have already been waiting for years for anything to happen at all. ;)