Author Topic: EZGUI  (Read 18281 times)

0 Members and 1 Guest are viewing this topic.

Chris Boss

  • Guest
Re: EZGUI
« Reply #15 on: March 25, 2018, 07:08:51 AM »
First, EZGUI already has an event engine. It preprocesses the most common window or notification messages and generates events with data about that event. By tapping into the EZ_Events routine one can easily tap into its event engine and just pass events on.

Second, I am not locked into only 32 bits, but the problem is that I have not yet found an alternative to Powerbasic which would make the porting of EZGUI practical at this point. EZGUI is way over 50,000 lines of code and that is a lot to port, no matter what I eventually use.

I don't use a lot of the fancy stuff in Powerbasic though (I don't use any DDT, no collections, few of the more extended versions of common commands, and no COM nor classes) so conversion may not be as bad as one would expect.

The biggest thing will probably be translating 32 bit API calls to their 64 counterparts. I don't always use the types found in the API inc files, but often use simpler data structures (ie. some API structures can be emulated using a LONG or DWORD array). I use LONG or DWORD for handles rather than a defined type like C headers do, so I would need to modify a lot of code for that when 64 bit requires a 64 bit data type.

The other problem is Powerbasic's use of OLE for strings. Only Oxygen so far is an alternative which does the same thing. I would have to modify a lot of subs/functions in my framework since I use strings extensively. This is why O2 interests me, its use of OLE strings.


JRS

  • Guest
Re: EZGUI
« Reply #16 on: March 25, 2018, 11:06:13 AM »
The only way to know if O2 is your solution is get started on the 64 bit version keeping your 32 bit version in PB.

Another suggestion is to maybe crowd fund your 64 bit version in O2.

chrisc

  • Guest
Re: EZGUI
« Reply #17 on: March 25, 2018, 09:05:55 PM »
Chris Boss
what John said is true, start converting form PB to O2 and you will find that it is NOT too difficult
as Charles and others are very helpful and can guide you along the way.

i being a beginner has already converted more than 10 of my programs to O2 with guidance from all our
pals in O2 forum. so this is not a big deal it can be done. a long journey require you to take a few steps first
and you would be on your way to a higher 64bits plane.

chrisc

  • Guest
Re: EZGUI
« Reply #18 on: March 25, 2018, 11:13:28 PM »
All Pb to O2  conversions

this is the list of commands/ guide lines which  i would use to convert my programs from PB to O2
hope that anyone else can share their thoughts in converting to O2, you can amend this list

Code: [Select]

conversion from PB to O2

conversion is indicated by -->

1. Find and strip off all $ in these functions

 MID$()   -->  MID()
 
 RIGHT$()   -->  RIGHT()

 LEFT$()    -->  LEFT()

 CHR$()    -->  CHR()

  SPACE$()  --> SPACE()

   STR$()  -->  STR()

   STRING$()  -->  STRING()

  TRIM$  --> you need to define it as
                     def trim ltrim(rtrim(%1))


   AND  --> &&



  2^7     -->  use power function  --> pow(2,7)




2.  There is no RANDOMIZE and RND() functions
  so need to add in
   Use Chaos 
   and use    irnd(3, 100 )

  irnd(3, 100 )   means getting a random integer between 3 and 100



 3.   Break up complex multiple functions line into smaller bits  for eg
       insXor = VAL("&H" + MID(value1, loopit, 1))   XOR   VAL("&H" + MID(value2, loopit, 1))

   use  the component step by step codes instead, otherwise the O2 compiler cannot compile
   and may returns error
          i1="&H" + MID(value1, loopit, 1)
          i2="&H" + MID(value2, loopit, 1)
          insXor=i1 xor i2




4.     ' Note that  in O2 we can assign strings to an integer number directly
        ' the compiler is VERY smart and adaptive
          tempnum = "&H" + MID(tempstr, loopit, 1)


             int a ,b
             a = 1
             b = "2"
           '  this results in 3
            PRINT a + b




5.  Try not to use  VAL function as it will convert the number to a float and gets error later on
     tempnum = VAL("&H" +"5E65A486")

    just use directly
       tempnum ="&H" +"5E65A486"




6.  In 64bit,    int no longer matches sys  may need to convert int to O2  sys  also applies to the following

       INTEGER ,  LONG , DWORD  -->  sys

      you need to test these functions out after conversion and most of the time it works for me


7.    BYTE --> int







Charles Pegge

  • Guest
Re: EZGUI
« Reply #19 on: March 26, 2018, 01:03:51 AM »
Well, I'm in the process of porting OxygenBasic to OxygenBasic, and getting a good dose of my own medicine, so to speak :)  As you may know, Oxygen is written in 32bit FreeBasic , and I want to ensure that the ported code is fully compatible with 64bit compiling.

o2 source code must be quite similar in size to that of EZGUI. But there are very few API calls. It is all Basic crunch-code with some Assembler.

For Types, and Typedefs I would recommend using the definitions documented for C/C++ at MSDN, rather than trying to adapt PB's 32bit definitions. We are currently using OpenGl C headers directly (from Khronos), and we have CoreWin for the Windows API.


Aurel

  • Guest
Re: EZGUI
« Reply #20 on: March 26, 2018, 01:18:15 AM »
Quote
I'm in the process of porting OxygenBasic to OxygenBasic
Charles
That would be great to see.
 :)

Mike Lobanovsky

  • Guest
Re: EZGUI
« Reply #21 on: March 26, 2018, 02:28:15 AM »
Well, I'm in the process of porting OxygenBasic to OxygenBasic...

That'd be really AWESOME to see!

In fact, that's the ultimate test to prove the compiler's viability. Once done and working, OxygenBasic may be declared BETA officially. :)

Charles Pegge

  • Guest
Re: EZGUI
« Reply #22 on: March 26, 2018, 03:20:53 AM »

I don't have to do very much, but the conversion has to be meticulous in every detail. So I'll be doing a lot of dry testing.

Once it's done, I can start to upgrade the low-basic it is written in, into something more abstract, and easier to handle.

Mike Lobanovsky

  • Guest
Re: EZGUI
« Reply #23 on: March 26, 2018, 07:34:41 AM »
Well, I'm in the process of porting OxygenBasic to OxygenBasic, and getting a good dose of my own medicine, so to speak :)  As you may know, Oxygen is written in 32bit FreeBasic , and I want to ensure that the ported code is fully compatible with 64bit compiling.

Gentlemen,

If you'd care to know my opinion, that's the statement that really deserves to be moved to the "Introducing OxygenBasic" board as a strategic, if not the decisive, point in Oxygen's development.

Bravo, Charles! :)

JRS

  • Guest
Re: EZGUI
« Reply #24 on: March 26, 2018, 10:41:39 AM »
The new Free BASIC.

Chris Boss

  • Guest
Re: EZGUI
« Reply #25 on: March 30, 2018, 11:47:54 AM »
Charles,

Would you be interested in a free copy of EZGUI 5.0 Pro ?

I still have one license to give away (a long time customer purchased 5 licenses and asked my to give them away to anyone who I thought would benefit the most from them).

If you would be interested, it may benefit O2 development in the following ways:

  • You can build your own Visual Designer front end for O2 if you like.
  • You can use EZGUI to make O2 fully compatible with it

Now if you can get O2 to work with the EZGUI runtime DLL, then I might be interested in doing the following:

  • Create a FREE version of my Designer to generate code, if you don't build one yourself
  • Producing a Lite version of EZGUI runtime (minimal features) which could be made available FREE for O2 users

If O2 could get a UI engine, even just one which can do the more common basic stuff, this could turn O2 into a more robust language. True it would be 32 bit for now, but it may be possible for me in the future to port EZGUI to 64 bit (if I can find the right tool to do this with).



JRS

  • Guest
Re: EZGUI
« Reply #26 on: March 30, 2018, 11:55:22 AM »
Chris,

That would be the best use of that license. I would send Charles a copy no matter what.

I still think a nag message if unregistered is better than a lite free copy.

Chris Boss

  • Guest
Re: EZGUI
« Reply #27 on: March 30, 2018, 12:10:42 PM »
Just for your info, EZGUI 5.0 Pro is lightyears ahead of Powerbasic when it comes to GUI stuff. It's command set is so large it could be considered a programming language in of itself.

The command set is nearly 1000 GUI commands, but many commands for example work with multiple control types.

For example, in DDT for example there is a unique command for clearing each control type. In API wrappers (ie. firefly) the same exists. But in EZGUI many commands for with multiple control types, for example EZGUI's EZ_Clear command works with the following controls:

Listbox
Combobox
Listview
Treeview
Tab control
Turtle Graphic control
Canvas control

In DDT this would be 7 different commands, but in EZGUI it is just one.

How does EZGUI do this ?

In situations where speed is not critical, I have many commands actually test the control to see what window class it is and then use the appropriate method of clearing the control specific to the control.

This means the EZGUI language is actually more robust than DDT (or API wrappers).

EZGUI apps do not require the WIN32 API header files (includes in PB). It has just one include with all its own definitions in it.

As a DLL, the UI framework allows one to build apps with tiny EXE's and have multiple EXE's share the same library. Kind of like with classic Visual Basic.

EZGUI is so easy to use one can even hand code complex user interfaces and apps.

EZGUI goes far beyond anything that Powerbasic alone can do or even any of the other PB Designers with their libraries. There are a number of proprietary engines in EZGUI which would be very difficult for the average Powerbasic user to emulate, such as:

Drag and Drop Visual Designer engine

This allows one to build actual programming language visual designers.

One of the biggest weaknesses in most indie BASIC's is their Form editors. The languages are ill suited to writing a designer. EZGUI though has this built in and it took me years to perfect it. Just to demonstrate:

If you use Firefly and try to select hundreds of controls at the same time and drag all of them, it is a mess (the designer the way it draws drag rectangles makes a mess of it). But with EZGUI it is easy and one can drag many hundreds of controls at one time smoothly.

EZGUI doesn't use place holders in the designer, but real controls. It subclasses the controls so the drag engine can handle dealing with them. For example in edit mode, the designer will trap all user input to the control, including any child controls it may have. When in run mode, the control works as normal. EZGUI has its own drag handle control which is used to display and implement the drag engine.

2D Canvas with proprietary 2D Sprite engine

No DirectX needed and it is a real control, not simply a full graphic window. I benchmarked it and it animated faster than Patrice Terries GDImage did with sprites.

3D Canvas control with real 3D objects and a full scripting language

The feature list is extensive. No current indie BASIC has a feature list so rich AFAIK.




Mike Lobanovsky

  • Guest
Re: EZGUI
« Reply #28 on: March 31, 2018, 01:13:29 AM »
Chris,

Just in case Charles would refuse your generous offer for any reason, please consider me as an alternative beneficiary.

Patrice Terrier

  • Guest
Re: EZGUI
« Reply #29 on: March 31, 2018, 06:13:50 AM »
Quote
I benchmarked it and it animated faster than Patrice Terries GDImage did with sprites.
Really...

Try to do this with EZGUI,
http://www.objreader.com/index.php?topic=26.0
or
http://www.objreader.com/index.php?topic=17.0
or
http://www.objreader.com/index.php?topic=80.0
then we can make fair comparisons.

And what about DWM composited mode support, and of course 64-bit ?

Here is a video showing what could be done witg GDImage 64-bit, including the hability to create amazing widget interface 100% graphic.
http://www.objreader.com/download/video/MBox64.mp4

...
« Last Edit: March 31, 2018, 06:26:28 AM by Patrice Terrier »