Print Page - EZGUI

Information => Reference => Topic started by: JRS on March 21, 2018, 04:14:05 PM

Title: EZGUI
Post by: JRS on March 21, 2018, 04:14:05 PM

Quote from: Chris Boss

You have been selected to get one of the FREE EZGUI 5.0 Professional (https://forum.powerbasic.com/forum/user-to-user-discussions/third-party-addons/770955-5-free-licenses-for-ezgui-to-give-away-details#post770955) licenses being offered.

Thanks Chris!

The plan is to use this copy of EZGUI to test under OxygenBasic and Script BASIC (via DLLC)

I will post my progress in this thread.

Title: EZGUI
Post by: JRS on March 23, 2018, 10:47:32 PM

Hi Roland,

Thanks for the getting started with O2 GUI forms programming examples.

Where is the callback function return variable used?

I'm playing around with EZGUI.DLL and Chris has three defined callbacks that require function pointers passed to define them. How is that done in O2?

Title: Re: EZGUI
Post by: Arnold on March 24, 2018, 12:28:51 AM

Hi John,

Charles has done many brilliant things in the accompanying include files. @Wndproc is provided in function MainWindow of WinUtil.inc. And of course there is also a basic Message Loop.

Roland

Title: Re: EZGUI
Post by: JRS on March 24, 2018, 12:45:45 AM

I think I'm going to use the same method for event handling in EZGUI as I did with IUP. Actually EZGUI will be easier as there are only 3 callback functions to support events.

Charles,

Is there a way I could create a virtual function with DLLC, get its function address pointer and pass it to EZGUI?

Title: Re: EZGUI
Post by: Charles Pegge on March 24, 2018, 02:39:47 AM

Hi John,

I think it must be similar to handling callbacks in IUP. These are handled by virtual functions, which service the callbacks, and pass data back to SB. projectsC\ScriptBasic\IUP

Title: Re: EZGUI
Post by: Chris Boss on March 24, 2018, 08:31:29 AM

A quick look at a GUI example in the examples folder of Oxygen, you simply use the @ character in front of the procedure or function name.

For example a window procedure called WinProc would use @WinProc for a pointer.

In PB: CODEPTR(WinProc)

In O2: @WinProc

In the ezwmain50.inc file of EZGUI you would change the three code pointer parameters for the EZ_GuiRun call from:

... CODEPTR(EZ_Main), CODEPTR(EZ_Events), CODEPTR(EZ_DesignWindow) ...

... @EZ_Main, @EZ_Events, @EZ_DesignWindow ...

There are other parameters in the EZ_GuiRun call and some may need to be modified to match O2 syntax, but the above solves the code pointer ones.

Does O2 have a MACRO command ?

One could write a Macro for any conversions from PB to O2.

Title: Re: EZGUI
Post by: JRS on March 24, 2018, 09:21:22 AM

Thanks Chris!

That was very helpful. I hope to have a Script BASIC / O2 EZGUI example posted soon.

Quote

Does O2 have a MACRO command?

Yes.

My plan is to let O2 (DLLC) (pre)process the raw EZGUI events at compiler code generation speeds and pass it off to Script BASIC once the event has been identified.

Title: Re: EZGUI
Post by: Chris Boss on March 24, 2018, 10:00:57 AM

If you can get EZGUI to work with O2 and ScriptBasic, I might consider making a freeware version with less features, kind of like an EZGUI Standard version. That way more would get to use it and then if they like it consider purchasing the Pro version. EZGUI is so feature rich now, that even a Free/Standard version would provide significant features.

Send me any examples of using EZGUI with O2 or ScriptBasic, so I can do some testing with them.

Title: Re: EZGUI
Post by: JRS on March 24, 2018, 10:46:51 AM

My suggestion is display a nag unregistered message if the EZGUI init is done with null values.

Title: Re: EZGUI
Post by: chrisc on March 24, 2018, 11:38:47 AM

Yes Chris Boss
You make our day, Sir

Please develop your EzGui program for O2 and make able to emit code in O2

Title: Re: EZGUI
Post by: JRS on March 24, 2018, 12:29:22 PM

There is money to pay for add-ons if the compiler is FREE.

Have we forgotten the after market of VB classic controls and widgets? O2 could bring that back.

Title: Re: EZGUI
Post by: Charles Pegge on March 24, 2018, 01:55:48 PM

O2 will support any standard DLL. Is EZGUI limited to 32bit at present, Chris?

The main task in supporting ScriptBasic would be to manage all the messages in a form that a script engine can cope with, filtering out mouse-move messages, and storing position, for instance.

Title: Re: EZGUI
Post by: jcfuller on March 24, 2018, 02:32:50 PM

Charles,
It's written in PowerBASIC I believe so it will always be 32bit.
Nort much use to me as I haven't done 32bit in years.

James

Title: Re: EZGUI
Post by: JRS on March 24, 2018, 08:46:24 PM

Quote from: Charles

The main task in supporting ScriptBasic would be to manage all the messages in a form that a script engine can cope with, filtering out mouse-move messages, and storing position, for instance.

My goal with message loops and event handlers is to have them only return events I have defined before starting the pump.

Title: Re: EZGUI
Post by: JRS on March 24, 2018, 08:49:12 PM

Quote from: jcfuller on March 24, 2018, 02:32:50 PM

Charles,
It's written in PowerBASIC I believe so it will always be 32bit.
Nort much use to me as I haven't done 32bit in years.

James

My hope is Chris hasn't been idle just because he was locked in a 32 bit box and has investigated what needs to change in EZGUI to go to 64 bit.

Title: Re: EZGUI
Post by: Chris Boss 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.

Title: Re: EZGUI
Post by: JRS 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.

Title: Re: EZGUI
Post by: chrisc 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.

Title: Re: EZGUI
Post by: chrisc 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

Title: Re: EZGUI
Post by: Charles Pegge 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.

Title: Re: EZGUI
Post by: Aurel 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.
:)

Title: Re: EZGUI
Post by: Mike Lobanovsky on March 26, 2018, 02:28:15 AM

Quote from: Charles Pegge on March 26, 2018, 01:03:51 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. :)

Title: Re: EZGUI
Post by: Charles Pegge 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.

Title: Re: EZGUI
Post by: Mike Lobanovsky on March 26, 2018, 07:34:41 AM

Quote from: Charles Pegge 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.

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! :)

Title: Re: EZGUI
Post by: JRS on March 26, 2018, 10:41:39 AM

The new Free BASIC.

Title: Re: EZGUI
Post by: Chris Boss 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).

Title: Re: EZGUI
Post by: JRS 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.

Title: Re: EZGUI
Post by: Chris Boss 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.

Title: Re: EZGUI
Post by: Mike Lobanovsky 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.

Title: Re: EZGUI
Post by: Patrice Terrier 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

...

Title: Re: EZGUI
Post by: JRS on March 31, 2018, 07:18:28 AM

Quote from: Mike Lobanovsky 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.

If Chris doesn't grant your request, the copy I have would be a better investment put to use in your hands.

Title: Re: EZGUI
Post by: Charles Pegge on March 31, 2018, 09:42:44 AM

Hi Chris,

I would be very interested to receive a copy of EZGUI, and see it in operation. I could investigate whether the outputs are directly usable by o2, or require a compatibility layer.

But before offering o2 as a potential 64bit compiler for EZGUI, I would like to get it through the Self-compile stage. (So far, so good. It may take another 3 weeks or so for run-time checks. (In its UPX-compressed form, it is about 123k, compared to the current 142k dll. )

Title: Re: EZGUI
Post by: Chris Boss on March 31, 2018, 12:41:58 PM

I was only highlighting EZGUI's performance with sprites, not making a full comparison between EZGUI and GDImage. The purpose of each tool is totally different. EZGUI is a GUI framework, not a Graphic framework.

I was also trying to highlight how much more EZGUI does than the core compiler (PB) does. Powerbasic programmers want all sorts of new features, but EZGUI has been doing many advanced things which the compiler can't even come close to doing. The PB compiler does not support sprites nor does it do 3D.

GDImage is an amazing graphic tool, no question there.

Title: Re: EZGUI
Post by: Chris Boss on March 31, 2018, 12:44:07 PM

Charles,

Send me an email to: chrisboss@centurylink.net or support@cwsof.com

Then I will send you the free copy of EZGUI 5.0 Pro.

Title: Re: EZGUI
Post by: Chris Boss on March 31, 2018, 01:00:15 PM

The key things a compiler requires to use EZGUI as a GUI framework are:

Support Include files for headers

EZGUI has two include files. One is simply all the sub/function declarations with things like constants and a few types defined. The second is actual working code. It contains a Winmain procedure which is where an EZGUI app technically starts. You do not define your own Winmain for an EZGUI, but must use its predefined Winmain. The WinMakes one call to EZGUI to a function called EZ_GUIRun. It passes parameters including three code pointers. This is where ones app starts up and EZ_GUIRun does not return until your app terminates. Then the Winmain ends and the app is terminated by Windows like normal.

What is in EZ_GUIRun and what are the three code pointers for ?

EZ_GUIRun contains all the initialization stuff for the framework and then executes a standard SDK style message loop, specific to how EZGUI works. EZGUI does your message processing, rather than you do it. You don't write a message loop for a normal EZGUI app.

The 3 code pointers are to 3 subroutines every EZGUI must have:

EZ_Main

This function is for your apps own startup code. You normally define things like the fonts, colors, etc. your forms will use and then must make at least one call to EZ_Form then command to create a new form. You can create more forms later in your code, but you must have at least one startup form created in EZ_Main.

When EZ_Main finishes, at least one form should be created by then and then control returns back to EZGUI's internal message loop.

Now every Form when create will generate a call to the second subroutine which a code pointer is passed to EZGUI, which is:

EZ_DesignWindow

This is kind of like processing WM_CREATE in SDK style apps, but it is a single routine called for every new forms created which has the name of the current form being created passed to it. One puts a Select case structure in it (one case for each form name) and then in that structure make calls to EZGUI commands to add controls or menus or other things.

Once the call to EZ_DesignWindow is finished, again control goes back to EZGUI.

Lastly, EZGUI forms all have their window procedures in the EZGUI runtime. EZGUI processes the most common ones and from them generates Events which it forwards to the third subroutine required:

EZ_Events

Events are much each to work with than window messages. EZGUI does a lot of complex message processing internally to make events easy to work with. For example in SDK style apps a scrollbar would require a lot of code in the WM_HSCROLL or WM_VSCROLL messages just to handle the movement of the scrollbar. EZGUI processes this for you and it generates a simple event, %EZ_Change, which it forwards to EZ_Events and it passes the event the newly calculated position of the scrollbar. It uses this same engine internally to also generate the %EZ_Change event for trackbars and the updown control as well.

EZGUI's event engine is where things are made much easier than in other styles of coding a Windows app.

Then to add to all of this is the huge command set EZGUI provides for you to do things within those events.

If a compiler can handle the include files (may need to be modified to match the compiler syntax), the winmain in one include and can pass code pointers then it can work with EZGUI. The only other issue is that EZGUI uses OLE strings for variable length string parameters, but O2 supports that.

Title: Re: EZGUI
Post by: chrisc on March 31, 2018, 01:16:51 PM

@Chris Boss

your propose EzGui for O2 will be good contribution for O2 advancement, thanxx a lot

Title: Re: EZGUI
Post by: Mike Lobanovsky on March 31, 2018, 02:23:32 PM

Quote from: Charles Pegge on March 31, 2018, 09:42:44 AM

I would be very interested to receive a copy of EZGUI, and see it in operation.
...................
So far, so good. It may take another 3 weeks or so for run-time checks.

Quote from: Chris Boss on March 31, 2018, 12:44:07 PM

I will send you the free copy of EZGUI 5.0 Pro.

+2 and +1 from me to your respective karmas, gentlemen. :)

Title: Re: EZGUI
Post by: JRS on March 31, 2018, 03:48:11 PM

Chris,

I would need to run EZGUI in a SB thread to make callbacks work. I going to follow Charles lead with O2.

Title: Re: EZGUI
Post by: Chris Boss on March 31, 2018, 07:54:27 PM

John,

Interfacing EZGUI to a scripting language would be more complex than interfacing it with a compiler. O2 should be easy, if one can write a simple WIN32 app with it using a Winmain and can do code pointers. A scripting engine is different and it takes control of code execution flow and that may be challenging for EZGUI.

To use a scripting language I would recommend passing full control to EZGUI. Then rather than define the three callbacks EZGUI requires in the users code, define them in the scripting engine. Then when the scripting engine gets the callbacks, read the users code and then execute it and make the calls to the EZGUI runtime when they require them.

Title: Re: EZGUI
Post by: JRS on April 01, 2018, 04:35:20 AM

Chris,

EZGUI would need an IUP callback function like IupLoopStepWait (https://webserver2.tecgraf.puc-rio.br/iup/en/func/iuploopstep.html) to work threadless in SB.

Title: Re: EZGUI
Post by: Chris Boss on April 01, 2018, 01:58:42 PM

EZGUI is designed for a normal single three model (the apps normal process thread).

Like I said, with a compiler not a problem, but with a scripting language one has to consider how the script language works under the hood and whether it can handle passing control to an external DLL. If not it likely won't work.

Title: Re: EZGUI
Post by: JRS on April 01, 2018, 03:51:52 PM

SB isn't good fit for EZGUI. I hope to have some fun with it under O2.

Title: Re: EZGUI
Post by: Chris Boss on April 07, 2018, 11:24:08 AM

Charles,

I just sent you an email with a Free License for EZGUI 5.0 Pro. Please feel free to email me any questions, especially those specific to using EZGUI with the O2 compiler. I can provide extra details about how the framework works under the hood so you can better work with it using O2.

Also if you find it works well, then I will seriously consider making a "lite" version specific for O2 which I could offer as freeware. This would increase the capabilities of O2, since it would make it much easier for O2 users to do all the GUI stuff. EZGUI is much easier to work with than Powerbasic's DDT and it also is well designed for even hand coding apps.

EZGUI uses a unique approach to Form design:

(1) It uses a character based coordinate system. DOS Basic programmers will find It easy to work with. The Windows Dialog technically is based on Character Units, but a dialog unit is 1/4 of the width of the system font and 1/8 height of the system font. In older versions of Windows this came out exactly to an 8 x 16 pixel character, so a dialog unit was always 2 pixels in size. In later versions of Windows this changed, which is why Dialog units are a pain. EZGUI uses the variable width system font (rather the Dialog units fixed width) and averages the size of a characters to define its character unit size. You define coordinates using Character units, rather than dialog units. But what makes it unique is that you can define character units using floating point numbers. This means you could define a character coordinate of say 1.5 units. This allows exact positioning and sizing down to the pixel level.

(2) A number of resources are handles similar to DOS. For example, colors are defined using index numbers rather than handles for brushes and pens. EZGUI predefines 32 colors at startup, which are the 16 standard DOS colors and 16 more which are pastel (lighter) versions of the previous 16. You can then define as many more colors as you desire. So to define the colors for a form or control you would do this:

EZ_Color FGColorIndex&, BGColorIndex&

and all the forms or controls created after this will get those colors, until you execute another EZ_Color command. So to make a control black text on white BG, you would:

EZ_Color 0, 15

Now that is just like DOS.

EZGUI handles the creation of brushes and pens in the background and then deletes then when the app terminates or when the EZ_FreeColor command. You can define hundreds of colors in EZGUI and free then on demand if you want to use different ones.

Fonts are handles just like colors. You define them with an Index and then you can simply select them as needed like this:

EZ_UseFont FontIndex&

No handles required and EZGUI cleans up when your app terminates.

To see how simple it is to code using EZGUI, here is an example of hand coding an app and you can see how little code it requires:

Code: [Select]

#COMPILE EXE
#DIM ALL
#INCLUDE "..\includes\ezgui50.inc"
#INCLUDE "..\includes\ezwmain50.inc"
' *********************  Application Constants and Declares ***************************
DECLARE SUB Form1_Events(CID&, CMsg&, CVal&, Cancel&)
%FORM1_LABEL1             = 100
%FORM1_BUTTON1            = 105
DECLARE SUB FORM1_BUTTON1_Click()
' *************************************************************************************

%UnitFlag   =   0        ' set to 1 to test unit width change

SUB EZ_Main(VerNum&)
    EZ_Color -1, -1
    EZ_Form "FORM1", "", "Your Dialog", 0, 0, 50, 18, "CK"
END SUB

SUB EZ_DesignWindow(FormName$)
    SELECT CASE FormName$
        CASE "FORM1"
              EZ_Color 0, 15
              EZ_DefFont 99, "Tahoma",  72, "BV"
              EZ_UseFont 99
              EZ_Label %FORM1_LABEL1, 1, 1, 48, 9, "Label  1", "CF"
              EZ_Color-1,-1
              EZ_UseFont -1
              EZ_Button %FORM1_BUTTON1, 12, 12, 27, 3, "Change Font Size", "T"
        CASE ELSE
    END SELECT
END SUB

SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
    SELECT CASE FormName$
        CASE "FORM1"
              SELECT CASE CID&
                  CASE %EZ_Window
                      IF CMsg&=%EZ_Close THEN
                      END IF
                  CASE  %FORM1_BUTTON1
                      IF CMsg&=%EZ_Click THEN
                          FORM1_BUTTON1_Click
                      END IF
                  CASE ELSE
              END SELECT
        CASE ELSE
    END SELECT
END SUB

SUB FORM1_BUTTON1_Click()
    LOCAL M$, MT$
    STATIC FW&
    IF %UnitFlag THEN
        M$="#"
        MT$="Units"
    ELSE
        M$="%"
        MT$="Percent"
    END IF
    IF FW&=0 THEN FW&=10
    IF FW&>=150 THEN FW&=10
    EZ_FreeFont 99
    EZ_DefFont 99, "Tahoma",  72, "BV["+TRIM$(STR$(FW&))+M$+"]"
    EZ_SetFont "Form1",%FORM1_LABEL1, 99
    EZ_SetText "Form1",0, CHR$(34)+EZ_GetFontName(99)+CHR$(34)+"    "+STR$(FW&)+" "+MT$+" width"
    FW&=FW&+10
END SUB

Unlike the Windows SDK or even DDT, EZGUI often uses simple text strings to define properties rather than use a bunch of bit flags in constants.

For example in the code above the EZ_Form command has a property string as the last parameter:

"CK"

The properties are usually just one capital character. In this case C stands for "Center Form" and K stands for Clipping (the controls) (C was already used for Center window, so I used K for Clipping).

For example a Textbox control would use the E character for Edit (meaning you can edit the text).

Once you get used to using these simple characters for properties one can almost memorize many commands.

Defining Fonts is similar. The line of code:

EZ_DefFont 99, "Tahoma", 72, "BV"

Means define a new font with an index of 99, using Tahoma font at 72 point size and the property string "BV" means Boldface and Variable width.

Title: Re: EZGUI
Post by: Chris Boss on April 07, 2018, 11:28:17 AM

Screenshot of app for code in previous post:

Title: Re: EZGUI
Post by: Chris Boss on April 07, 2018, 11:30:31 AM

Entire apps can be made using EZGUI with just three subroutines (all EZGUI apps must have these three subroutines):

EZ_Main

EZ_DesignWindow

EZ_Events

Even with multiple forms one can still just use these three routines.

Title: Re: EZGUI
Post by: JRS on April 07, 2018, 12:21:32 PM

Sure looks EZ to me. 8)

Title: Re: EZGUI
Post by: Charles Pegge on April 07, 2018, 09:52:47 PM

Many thanks Chris,

That looks very straightforward. I have downloaded and installed EZGUI-5, and I'll give it a go ASAP :)

Title: Re: EZGUI
Post by: chrisc on April 08, 2018, 07:19:11 AM

@Chris Boss

you are the Boss, make O2 Ezgui visual designer, we truly need it.

Title: Re: EZGUI
Post by: Chris Boss on April 08, 2018, 04:00:02 PM

Charles, there is an interesting market for your Oxygen compiler. You could tap into this market with the free compiler optimized for it and then later, if you have a need or desire, find other ways to monetize your efforts. What is this market ?

Windows 10 IOT Core

This new version of Windows is targeted for so called "makers" of IOT style devices. The Raspberry PI is a big hit today, but there is a growing market of x86 based "maker" devices. The embedded world (which Windows 10 IOT is part of) is also very big.

I found something very interesting. It is a list of WIN32 API's supported by "all" versions of Windows, which I assume also means the free IOT version. You could easily use this as a basis of building a IOT version of the O2 compiler which is guaranteed compatible with Windows 10 IOT Core (free version).

If you have no need tp monetize O2 in anyway, it is still a desirable area for development, especially since the "maker" market is not big and there is a lot of interest in it in education, small tech startups, etc.

Here is the list of supported API's:

https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis (https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis)

I did a quick check it is supports both the OLE API's ( both PB OLE strings and O2 strings) and also the console API's, which means it might support PB Console compiler right out of the box (except graphic window).

Title: Re: EZGUI
Post by: JRS on April 08, 2018, 05:43:11 PM

I could spend the rest of my life defining these with DLLC. :)

I do like the format of the documentation.

I'm planning on using a SQLite DB to store Script BASIC documentation and create a generic help viewer to display it in. Search comes as a welcome byproduct

Title: Re: EZGUI
Post by: JRS on April 08, 2018, 08:01:05 PM

I could link this global API monster with a scriba build and use DLLC to map the already loaded library functions I might need for a current script I might be writing.

Title: Re: EZGUI - WoW
Post by: JRS on April 12, 2018, 10:20:59 PM

I installed EZGUI on Wine. It seems to be working fine. I need to get PB10 installed so I can compile code until Chris has a O2 designer and code generator. (hopefully 64 bit)

Title: Re: EZGUI
Post by: Chris Boss on April 13, 2018, 04:10:01 PM

John,

A number of my customers use EZGUI regularly on Linux using Wine and have reported it works very well.

EZGUI does not lean towards the "bleeding edge" in the Windows API, but instead leans on the more long time API's which are proven and core to most versions of Windows. This makes it run better on Wine than some other stuff which leans towards newer API's. For example, EZGUI uses a proproprietary Graphic engine for its sprite engine based on the Windows DIB API's, which have existed since Windows 95. EZGUI performed slightly faster in sprite animation than Patrice Terriers GDImage and doesn't use anything like GDI Plus.

EZGUI also uses OpenGL 1.0/2.0 for 3D, so it is better suited to Wine which does OpenGL well.

The feature set of EZGUI is rich and extensive, but yet most of it should work well with Wine.

Title: Re: EZGUI
Post by: JRS on April 13, 2018, 04:25:57 PM

The only problem so far is that EZGUI dumps tons of non-functional .lnk shortcuts on my Linux desktop.

If I start EZGUI from the console, I can get the .lnk files to work using the following Wine command.

wine start "EZGUI 5.0 Designer.lnk"

Title: Re: EZGUI
Post by: Charles Pegge on April 13, 2018, 09:02:12 PM

Hi Chris

Quote

Windows 10 IOT Core

This new version of Windows is targeted for so called "makers" of IOT style devices. The Raspberry PI is a big hit today, but there is a growing market of x86 based "maker" devices. The embedded world (which Windows 10 IOT is part of) is also very big....

Thanks for the info. I'm also interested in ARM-based devices, and others like the PIC microcontrollers, with tiny instruction sets. But my primary focus will be on x86.

Title: Re: EZGUI
Post by: JRS on April 21, 2018, 11:07:41 AM

Chris,

It would be to your benefit to show a few examples of calling your ezgui.dll from O2. It shouldn't be that difficult. Your BASIC compiler is open source, supported and FREE. (not to mention a viable 64 bit migration path)

Title: EZGUI
Post by: JRS on April 21, 2018, 01:56:10 PM

Chris,

I compiled your MDI demo with PB10 but I'm having a problem with the .PBR being generated. I checked the box in the PBIDE but it never gets generated. What am I doing wrong? I REM'ed out the #RESOURCE line and it compiled and looks fine to me.

Code: QBasic/QuickBASIC

' *************************************************************************************
'                    Code Generated by EZGUI Professional Visual Designer 5.0
'           Portions: Copyright Christopher R. Boss, 2003 to 2011 All Rights Reserved !
'              Registered EZGUI 5.0 users may use generated code Royalty Free !
' *************************************************************************************
'
' -----------------------------------------------------------------------------------------
'            WARNING !    Do Not Modify any code WITHIN Protected Sections !
' You can add code (Sub,Function,etc.) BEFORE any Protected Routine by using the following
' CODE TAGS:        '<<SAVE>>      '<<END>>            and the Designer will not remove it.
' -----------------------------------------------------------------------------------------
'
 
' ======================================
' [PROTECTED CODE]         Do NOT Edit !
' ======================================
 
 
'
#COMPILE EXE
#DIM ALL        '   This is helpful to prevent errors in coding
' --------------------
#INCLUDE "C:\ezgui50pro\includes\ezgui50.inc"                          ' EZGUI Include file for Declares
' --------------------
' #RESOURCE ".\rcdata\MDIapp.pbr"
' *************************************************************************************
 
 
' *************************************************************************************
'                   Code Generator Defined Constants and Declares
' *************************************************************************************
DECLARE FUNCTION Main_Initialize(BYVAL VerNum&) AS LONG
DECLARE SUB OtherForm_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
DECLARE SUB OtherForm_Design(FormName$)                            a
DECLARE FUNCTION PreProcess_Events(FormName$, CID&, CMsg&, CVal&, Cancel&) AS LONG
DECLARE SUB EZ_MDIPARENT_Display(BYVAL FParent$)
DECLARE SUB EZ_MDIPARENT_Design()
DECLARE SUB EZ_MDIPARENT_ParseEvents(CID&, CMsg&, CVal&, Cancel&)
DECLARE SUB MDIPARENT_Events(CID&, CMsg&, CVal&, Cancel&)
' ------------------------------------------------
 
 
' ----------------------------------------------------------
%MDIPARENT_MENUFILES                              = 9000
' ----------------------------------------------------------
%MDIPARENT_MENUNEW                                = 9005
%MDIPARENT_MENUOPEN                               = 9010
%MDIPARENT_MENUSAVE                               = 9015
%MDIPARENT_MENUCLOSE                              = 9020
%MDIPARENT_SEPARATOR_9025                         = 9025
%MDIPARENT_MENUEXIT                               = 9030
 
' ----------------------------------------------------------
%MDIPARENT_MENUWIN                                = 9100
' ----------------------------------------------------------
%MDIPARENT_MENUTILE                               = 9105
%MDIPARENT_TOOLBAR1           = 50
%MDIPARENT_MDICLIENT1         = 25
%MDIPARENT_STATUSBAR          = 105
 
DECLARE SUB MDIPARENT_TOOLBAR1_Events(BYVAL TBarID&, MyID&, BYVAL ButtonN&, CMsg&, CVal&, Cancel&)
DECLARE SUB EZ_MDICHILD_Display(BYVAL FParent$, BYVAL AC!, BYVAL AR!)
DECLARE SUB EZ_MDICHILD_Design()
DECLARE SUB EZ_MDICHILD_ParseEvents(CID&, CMsg&, CVal&, Cancel&)
DECLARE SUB MDICHILD_Events(CID&, CMsg&, CVal&, Cancel&)
' ------------------------------------------------
 
%MDICHILD_TEXT1              = 100
 
DECLARE SUB MDICHILD_TEXT1_Events(MyID&, CMsg&, CVal&, Cancel&)
 
 
 
' *************************************************************************************
'                 Code Generator Defined Global Variables and Types
' *************************************************************************************
 
 
 
'    Note:     Do NOT change the names of the EZGUI Callback Procedures !
 
' --------------------
#INCLUDE "C:\ezgui50pro\includes\ezwmain50.inc"                          ' EZGUI Include file for WinMain
' --------------------
 
 
 
' *************************************************************************************
'                       User Defined Global Variables and Types
'         (Put code in CODE TAGS! to protect from deletion by Code Generator !)
' *************************************************************************************
 
SUB EZ_Main(VerNum&)     ' (PROTECTED)
     EZ_Reg %EZ_USER,%EZ_REGNUM
     EZ_DefImageFolder "Graphics"
     EZ_AllowCommandEvents  0
     EZ_LoadImageLib ""
     EZ_DefFont 6, "Arial", 10, "V"
     EZ_DefFont 7, "Courier New", 10, "F"
     EZ_DefFont 8, "Times New Roman", 10, "V"
     EZ_DefFont 9, "Modern", 10, "V"
     EZ_DefSystemColor 32, 4
     EZ_DefSystemColor 33, 5
     EZ_DefSystemColor 34, 15
     EZ_DefSystemColor 35, 24
     EZ_DefColorL 36, &H00B96FFF
     EZ_DefColorL 37, &H0014AB9F
     EZ_DefColorL 38, &H0047A7FF
     EZ_DefColorL 39, &H00D2AACF
     EZ_DefColorL 40, &H001CD5E3
     EZ_DefColorL 41, &H00BC8943
     EZ_DefColorL 42, &H006C6AB7
     EZ_DefColorL 43, &H00DD4489
     IF Main_Initialize(VerNum&) THEN
          EZ_MDIPARENT_Display ""
     END IF
END SUB
 
' -------------------------------------------------------------------------------------
 
SUB EZ_DesignWindow(FormName$)     ' (PROTECTED)
     SELECT CASE FormName$
          CASE "MDIPARENT"
               EZ_MDIPARENT_Design
          CASE "MDICHILD"
               EZ_MDICHILD_Design
          CASE ELSE
               OtherForm_Design FormName$
     END SELECT
END SUB
 
' -------------------------------------------------------------------------------------
 
SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)     ' (PROTECTED)
     IF PreProcess_Events(FormName$, CID&, CMsg&, CVal&, Cancel&) THEN EXIT SUB
     SELECT CASE FormName$
          CASE "MDIPARENT"
               EZ_MDIPARENT_ParseEvents CID&, CMsg&, CVal&, Cancel&
          CASE "MDICHILD"
               EZ_MDICHILD_ParseEvents CID&, CMsg&, CVal&, Cancel&
          CASE ELSE
               OtherForm_Events FormName$, CID&, CMsg&, CVal&, Cancel&
     END SELECT
END SUB
 
' -------------------------------------------------------------------------------------
     ' my library stuff
' *************************************************************************************
'                                Applications FORM Code
' *************************************************************************************
' ======================================
' [USER ACCESSABLE CODE]  You may Edit !
' ======================================
 
FUNCTION Main_Initialize(BYVAL VerNum&) AS LONG
     LOCAL RV&
     RV&=1
     FUNCTION=RV&
END FUNCTION
 
 
SUB OtherForm_Design(FormName$)
     SELECT CASE FormName$
          CASE ELSE
     END SELECT
END SUB
 
 
SUB OtherForm_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
     SELECT CASE FormName$
          CASE "{OPENDLG}", "{SAVEDLG}", "{OPENDLGX}", "{SAVEDLGX}", "{COLORDLG}", "{FONTDLG}", "{PRINTDLG}", "{PAGEDLG}", "{FINDDLG}"
          CASE "{ABORTDLG}"
          CASE "{MSGBOX}"
          CASE ELSE
     END SELECT
END SUB
 
 
FUNCTION PreProcess_Events(FormName$, CID&, CMsg&, CVal&, Cancel&) AS LONG
     LOCAL RV&
     RV&=0
     FUNCTION=RV&
END FUNCTION
 
 
'<<BEGINFORM>> "MDIPARENT"
 
 
' ======================================
' [PROTECTED CODE]         Do NOT Edit !
' ======================================
 
SUB EZ_MDIPARENT_Display(BYVAL FParent$)     ' (PROTECTED)
     LOCAL hMainMenu&
     ' Main Menu handle automatically stored by EZGUI
     hMainMenu&=EZ_DefMainMenu( %MDIPARENT_MENUFILES, "&File", "")
     EZ_Color -1, -1
     EZ_Form "MDIPARENT", FParent$, "EZGUI Editor", 0, 0, 75, 25, "^_CZ{MDI-P}"
END SUB
 
SUB EZ_MDIPARENT_Design()     ' (PROTECTED)
     LOCAL CText$
     LOCAL hMainMenu&, hDropMenu&, hSubMenu&
     hMainMenu&=EZ_GetMenu("MDIPARENT", 0)
     EZ_AddMenuItem hMainMenu&, %MDIPARENT_MENUWIN, 0, "&Windows", ""
     hDropMenu&=EZ_DefSubMenu( %MDIPARENT_MENUNEW, "&New File", "")
     EZ_SaveMenu "MDIPARENT", 1, hDropMenu&
     EZ_SetSubMenu hMainMenu& , %MDIPARENT_MENUFILES, hDropMenu&
     EZ_AddMenuItem hDropMenu&, %MDIPARENT_MENUOPEN, 0, "&Open File", ""
     EZ_AddMenuItem hDropMenu&, %MDIPARENT_MENUSAVE, 0, "&Save File", ""
     EZ_AddMenuItem hDropMenu&, %MDIPARENT_MENUCLOSE, 0, "&Close File", ""
     EZ_AddMenuItem hDropMenu&, %MDIPARENT_SEPARATOR_9025, 0, "-", ""
     EZ_AddMenuItem hDropMenu&, %MDIPARENT_MENUEXIT, 0, "E&xit", ""
     hDropMenu&=EZ_DefSubMenu( %MDIPARENT_MENUTILE, "&Tile Windows", "M")
     EZ_SaveMenu "MDIPARENT", 2, hDropMenu&
     EZ_SetSubMenu hMainMenu& , %MDIPARENT_MENUWIN, hDropMenu&
     ' ------------------------------------------------
 
     EZ_Color-1,-1
     EZ_UseFont 4
     STATIC PN1$
     IF PN1$ = "" THEN PN1$ = EZ_LoadPicture("%EZMTOOLBAR{S}")
     EZ_UseAutoSize "CT"
     EZ_Toolbar %MDIPARENT_TOOLBAR1, PN1$,  "BBBB|0124{New|Open|Save|Close|}", "RT24X24"
     ' -----------------------------------------------
     EZ_Color-1,-1
     EZ_UseFont 4
     EZ_MDIClient
     ' -----------------------------------------------
     EZ_Color -1,-1
     EZ_UseFont 4
     EZ_AllowLoadingEvent 2
     EZ_StatusBar %MDIPARENT_STATUSBAR, "", ""
     EZ_ResizeMDI "MDIParent", 0, 4,0,0,1
     EZ_AddAutoSize "MDIParent", 25, "CT"
END SUB
 
' ======================================
' [USER ACCESSABLE CODE]  You may Edit !
' ======================================
'<<SAVE>>
SUB DoFileAccess(BYVAL F$, BYVAL Mode&)
     LOCAL T$, AFN%
     AFN%=FREEFILE
     IF Mode&=1 THEN
          IF DIR$(F$)<>"" THEN KILL F$
          T$=EZ_GetText("MDIChild",%MDICHILD_TEXT1)
     ELSE
          IF DIR$(F$)="" THEN EXIT SUB
          T$=""
     END IF
     OPEN F$ FOR BINARY AS AFN%
     IF Mode&=1 THEN
          PUT$ AFN%, T$
     ELSE
          GET$ AFN%, LOF(AFN%), T$
          EZ_SetText "MDIChild",%MDICHILD_TEXT1, T$
     END IF
     CLOSE AFN%
     EZ_SetText "MDIChild",0, F$
END SUB
SUB DoTextFile(BYVAL Mode&)
     LOCAL AF$, F$
     SELECT CASE Mode&
          CASE 0    ' New file
               GOSUB TestForForm
               EZ_SetText "MDIChild", %MDICHILD_TEXT1, ""
               EZ_SetText "MDIChild", 0, "newtext.txt"
          CASE 1    ' Open
               GOSUB TestForForm
               F$=EZ_OpenFile("MDIParent","Select Text File","", "Text (*.txt))|*.txt|All Files (*.*)|*.*|","Z")
               IF F$<>"" THEN
                    DoFileAccess F$, 0
               END IF
          CASE 2,3    ' save
               IF EZ_Handle("MDIChild",0)<>0 THEN
                    IF EZ_IsForm("MDIChild", "Min") THEN EZ_MaximizeForm  "MDIChild"
                    AF$=EZ_GetText("MDIChild",0)
                    F$=EZ_SaveFile("MDIParent","Save Text File","", AF$, "Text (*.txt))|*.txt|All Files (*.*)|*.*|","txt", "PNIZ")
                    IF F$<>"" THEN
                         DoFileAccess F$, 1
                    END IF
                    IF Mode&=3 THEN EZ_UnloadForm "MDIChild"
               END IF
     END SELECT
     EXIT SUB
     TestForForm:
          IF EZ_Handle("MDIChild",0)=0 THEN
               EZ_MDIchild_Display "MDIParent", 0,0
               EZ_MaximizeForm "MDIChild"
          END IF
          IF EZ_IsForm("MDIChild", "Min") THEN EZ_MaximizeForm  "MDIChild"
     RETURN
END SUB
'<<END>>
 
SUB MDIPARENT_MenuEvents(BYVAL MyID&, CMsg&, CVal&, Cancel&, BYVAL hMenu&, BYVAL MenuText$)
     SELECT CASE MyID&
          CASE %MDIPARENT_MENUFILES
               SELECT CASE CMsg&
                    CASE %EZ_Click
                    CASE %EZ_Selected
               END SELECT
          CASE %MDIPARENT_MENUNEW
               SELECT CASE CMsg&
                    CASE %EZ_Click
                         DoTextFile 0
                    CASE %EZ_Selected
               END SELECT
          CASE %MDIPARENT_MENUOPEN
               SELECT CASE CMsg&
                    CASE %EZ_Click
                         DoTextFile 1
                    CASE %EZ_Selected
               END SELECT
          CASE %MDIPARENT_MENUSAVE
               SELECT CASE CMsg&
                    CASE %EZ_Click
                         DoTextFile 2
                    CASE %EZ_Selected
               END SELECT
          CASE %MDIPARENT_MENUCLOSE
               SELECT CASE CMsg&
                    CASE %EZ_Click
                         DoTextFile 3
                    CASE %EZ_Selected
               END SELECT
          CASE %MDIPARENT_MENUEXIT
               SELECT CASE CMsg&
                    CASE %EZ_Click
                    CASE %EZ_Selected
               END SELECT
          CASE %MDIPARENT_MENUWIN
               SELECT CASE CMsg&
                    CASE %EZ_Click
                    CASE %EZ_Selected
               END SELECT
          CASE %MDIPARENT_MENUTILE
               SELECT CASE CMsg&
                    CASE %EZ_Click
                    CASE %EZ_Selected
               END SELECT
          CASE ELSE
     END SELECT
END SUB
 
 
' ======================================
' [PROTECTED CODE]         Do NOT Edit !
' ======================================
 
 
SUB EZ_MDIPARENT_ParseEvents(CID&, CMsg&, CVal&, Cancel&)     ' (PROTECTED)
     SELECT CASE CID&
          CASE %EZ_Window
               MDIPARENT_Events CID&, CMsg&, CVal&, Cancel&
          CASE %MDIPARENT_MENUFILES
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 0), "&File"
          CASE %MDIPARENT_MENUNEW
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 1), "&New File"
          CASE %MDIPARENT_MENUOPEN
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 1), "&Open File"
          CASE %MDIPARENT_MENUSAVE
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 1), "&Save File"
          CASE %MDIPARENT_MENUCLOSE
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 1), "&Close File"
          CASE %MDIPARENT_SEPARATOR_9025
          CASE %MDIPARENT_MENUEXIT
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 1), "E&xit"
          CASE %MDIPARENT_MENUWIN
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 0), "&Windows"
          CASE %MDIPARENT_MENUTILE
               MDIPARENT_MenuEvents CID&, CMsg&, CVal&, Cancel&, EZ_GetMenu("MDIPARENT", 2), "&Tile Windows"
          CASE  %MDIPARENT_TOOLBAR1
               MDIPARENT_TOOLBAR1_Events CID&, CID&, 0, CMsg&, CVal&, Cancel&      ' Main Toobar ID
          CASE  %MDIPARENT_TOOLBAR1+1 TO  %MDIPARENT_TOOLBAR1+4
               LOCAL TBNum&
               TBNum& = CID&- %MDIPARENT_TOOLBAR1
               MDIPARENT_TOOLBAR1_Events  %MDIPARENT_TOOLBAR1, CID&, TBNum&, CMsg&, CVal&, Cancel&
          CASE ELSE
               MDIPARENT_Events CID&, CMsg&, CVal&, Cancel&
     END SELECT
END SUB
 
' ======================================
' [USER ACCESSABLE CODE]  You may Edit !
' ======================================
 
SUB MDIPARENT_Events(CID&, CMsg&, CVal&, Cancel&)
     SELECT CASE CID&
          CASE %EZ_Window
               SELECT CASE CMsg&
                    CASE %EZ_Loading
                    CASE %EZ_Loaded
                         EZ_SetFormIcon "MDIParent",EZ_LoadIcon("%EZEZ")
                    CASE %EZ_Started
                         EZ_MDIchild_Display "MDIParent", 0,0
                         EZ_MaximizeForm "MDIChild"
                    CASE %EZ_Size
                         EZ_ResizeMDI "MDIParent",0,0,0,0,1
                    CASE %EZ_Close
                    CASE ELSE
               END SELECT
          CASE ELSE
     END SELECT
END SUB
 
 
SUB MDIPARENT_TOOLBAR1_Events( BYVAL TBarID&, MyID&, BYVAL ButtonN&, CMsg&, CVal&, Cancel&)
     SELECT CASE CMsg&
          CASE %EZ_Click
               DoTextFile ButtonN&-1
          CASE ELSE
     END SELECT
END SUB
 
 
 
'<<BEGINFORM>> "MDICHILD"
 
 
' ======================================
' [PROTECTED CODE]         Do NOT Edit !
' ======================================
 
SUB EZ_MDICHILD_Display(BYVAL FParent$, BYVAL AC!, BYVAL AR!)     ' (PROTECTED)
     EZ_Color -1, -1
     EZ_Form "MDICHILD", FParent$, "newtext.txt", AC!, AR!, 44, 17, "^_Z{MDI-C}"
END SUB
 
SUB EZ_MDICHILD_Design()     ' (PROTECTED)
     LOCAL CText$
     EZ_Color-1,-1
     EZ_UseIFont "Courier New", 16,"L+F"
     EZ_UseAutoSize "CT"
     EZ_Text %MDICHILD_TEXT1, 0, 0, 44, 17, "", "BEMSTV"
     ' -----------------------------------------------
END SUB
 
 
SUB EZ_MDICHILD_ParseEvents(CID&, CMsg&, CVal&, Cancel&)     ' (PROTECTED)
     SELECT CASE CID&
          CASE %EZ_Window
               MDICHILD_Events CID&, CMsg&, CVal&, Cancel&
          CASE  %MDICHILD_TEXT1
               MDICHILD_TEXT1_Events CID&, CMsg&, CVal&, Cancel&
          CASE ELSE
               MDICHILD_Events CID&, CMsg&, CVal&, Cancel&
     END SELECT
END SUB
 
' ======================================
' [USER ACCESSABLE CODE]  You may Edit !
' ======================================
'<<SAVE>>
SUB ResizeTextBox(BYVAL FormName$, BYVAL ID&)
     LOCAL W!, H!
     EZ_GetSize FormName$, W!, H!, 0
     EZ_ResizeC FormName$, ID&,0,0, W!, H!
END SUB
'<<END>>
 
SUB MDICHILD_Events(CID&, CMsg&, CVal&, Cancel&)
     SELECT CASE CID&
          CASE %EZ_Window
               SELECT CASE CMsg&
                    CASE %EZ_Loading
                    CASE %EZ_Loaded
                    CASE %EZ_Focus
                         EZ_SetDlgMsgMode 0
                    CASE %EZ_NoFocus
                         EZ_SetDlgMsgMode 1
                    CASE %EZ_Started
                    CASE %EZ_Close
                    CASE %EZ_Size
                         ResizeTextBox "MDIChild", %MDICHILD_TEXT1
                    CASE ELSE
               END SELECT
          CASE ELSE
     END SELECT
END SUB
 
 
SUB MDICHILD_TEXT1_Events( MyID&, CMsg&, CVal&, Cancel&)
     SELECT CASE CMsg&
          CASE %EZ_Change
          CASE ELSE
     END SELECT
END SUB
 
 
 
'<<END ALL FORMS>>    UnKnown Routines follow:
#IF %EZ_NOSKIPCODE
#ENDIF 'PARSE END
 

Title: Re: EZGUI
Post by: Chris Boss on April 21, 2018, 02:14:03 PM

John,

The EZGUI Designer generates the Resource file, but you have to make sure it gets compiled so you get a PBR file. You can do than manually in the PB IDE or you can go into the EZGUI Designer and it the project properties dialog you can select an option to run the RC.EXE utility that comes with PB automatically. Check out my forums for more info about how to do that. It is there.

See: http://cwsof.com/forums/index.php?topic=806.0 (http://cwsof.com/forums/index.php?topic=806.0)

Title: Re: EZGUI
Post by: JRS on April 21, 2018, 03:00:23 PM

Chris,

Thanks! That fixed it.

Compiling "C:\ezgui50pro\examples\MDI\MDIapp_source\MDIapp.bas" Successfully created "C:\ezgui50pro\examples\MDI\MDIapp_source\MDIapp.EXE"

Is there anyway to eliminate the flicker in the toolbar when resizing the main window?

BTW: I noticed the nag dialog since I didn't insert my registration info in the code. This is what I have been asking you to do and it seems it's already works this way. Why haven't you posted an unregistered copy of EZGUI and let people play with it until they buy it?

Title: Re: EZGUI
Post by: JRS on May 05, 2018, 11:12:28 AM

Chris Boss,

Any news where you are with examples of EZGUI.dll being used with O2?

Title: Re: EZGUI
Post by: Charles Pegge on May 05, 2018, 01:28:49 PM

Not yet, John. o2 self-compiling needs to come first.

Title: Re: EZGUI
Post by: JRS on May 05, 2018, 01:31:01 PM

Charles,

That question was for Chris Boss not you.

Title: Re: EZGUI
Post by: JRS on June 12, 2018, 01:24:10 AM

Hey Chris,

Have you given up getting your EZGUI DLL working under O2?

Title: Re: EZGUI
Post by: Chris Boss on June 12, 2018, 07:02:38 AM

No !

Just been busy with custom programming for a client. I have to work for a living. Been working on using PB CC with a real time OS.

So when I get some time to play around I will see what I can do with O2 and EZGUI.

Title: Re: EZGUI
Post by: JRS on June 12, 2018, 09:57:40 AM

I'm in the same boat with getting ScriptO2 to float.

Title: Re: EZGUI
Post by: Mike Lobanovsky on June 12, 2018, 04:42:48 PM

It looks like Brian is in the same boat as well. We haven't heard from him either for quite some time now.

Title: Re: EZGUI
Post by: JRS on June 13, 2018, 07:14:12 AM

Quote

It looks like Brian is in the same boat as well.

I keep hoping Eros will give up on PowerBASIC and try converting ThinBasic to O2. He already has O2 as an extension like SB but not as extensive.

Title: Re: EZGUI
Post by: JRS on June 14, 2018, 02:05:50 PM

Hi Chris,

Does EZGUI work with ThinBasic?

Only offering a PowerBASIC solution is like riding around in a hearse.

(https://irp-cdn.multiscreensite.com/94ea2b03/dms3rep/multi/mobile/motorcycle-hearse.jpg)

Oxygen Basic

Information => Reference => Topic started by: JRS on March 21, 2018, 04:14:05 PM