Using third party addons

[Patrice Terrier]

--Theo

No doubt that EZGui is a good product for people with a limited knowledge of the Windows programming and working only for themself.

But when you do, like myself, a programming consultant job, then you must use some kind of market standard.
And when you must provide the source code of your work, it is impossible to use a third party addon, if it is not itself a standard.

Learning a proprietary syntax, is not harder than learning the core API. Ask yourself, does Chris would have been able to write EZGUI without learning SDK programming. 

...

[Theo Gottwald]

--Patrice

then you must use some kind of market standard.

PB itself is not a market standard. Nobody knows, what would happen with it,if one day (god may beware of)
Bob would go to his Island in the Caribean Ocean :-).

At the end you are there with what you have.
In some way, the usage of EZGUI and your Graphic-Control are very similar.

You get predefined subroutines from someone who has invested a lot of time into it,
and you benefit from this invested time, because your project is more quickly ready.

Learning a proprietary syntax,

While I agree with you that learning a proprietary syntax like DDT is somehow like a "One-way road",
i already stated that the step from EZGUI to SDK is less then the step from DDT to SDK.

Also people should not intermix DDT and SDK, while there are no such limitations with EZGUI.
I think it is a god sollution to speed up projects therefore.

At the end, PB itself does not provide the comfort of a RAD-Tool.
If you really want to make something quick, you will think of external tools and libraries
wether for graphics or for windows tasks. At the end its a DLL somehow like your product.

PS: If you want to discuss this topic, maybe we can make an own topic in my forum under third party.
I think its a good idea to share different opinions about using external tools.

[Patrice Terrier]

PB itself is not a market standard

I do not agree, if you stay away of DDT, PowerBASIC uses a plain BASIC language that is easy to translate to any other BASIC dialect, and even to C.
 

In some way, the usage of EZGUI and your Graphic-Control are very similar

No, because one is a control component (GDImage), while the other produces proprietary code that relies on an external runtime (EZGUI).
Moreover people can buy the GDImage source code, while you can't buy EZGUI's.
When you use a component you can change it to another if it doesn't match anymore your need, but what will you do with your whole code if you come to a dead end, then no other solution than learning a new language.

For me, CreateWindowEx will be always the same what ever the language being used 

PS: If you want to discuss this topic, maybe we can make an own topic in my forum under third party.
I think its a good idea to share different opinions about using external tools.

Feel free to move this post out of the EZGUI thread, beause it is more a question of philosophy than anything else.

[Theo Gottwald]

For me its not so much a philosophical question as a practical question. For example, I do not agree with Chris, when he wrote me this:

I also strongly believe that programmers must be willing to do some of the work in writing applications.
The concept of EZ (easy) to use, does not mean no effort. It just means that the steps are not usually overly complicated.
One of the problems with programming today, is that programmers want the computer (or software) to everything and not themselves. I don't agree with this concept. I think programmers should be able to write code and lots of it. The purpose of EZGUI is not to relief the program from coding, but to simply make it faster and easier, also giving him the tools to solve problems.

We are living in the time of 4GL Languages. Last week an ex-PB customer sent me an e-mail. He said he is now using a "4GL" language.

He wrote:

hier der Link zur Visual DataFex
http://www.visualdataflex.com/Home.asp?pageid=569

Das Produkt kostet um die 1.000,- Euro incl. 1 Jahr Wartung und jedes weitere Jahr Wartung ca. 350,- Euro.
Für den Kunden kommen dann noch Runtime Lizenzen pro Platz mit 60,- Euro incl. 1 Jahr Wartung und jedes weitere Jahr Wartung ca. 30,- Euro hinzu.

Eine Visual DataFlex Personal ist frei für non-commercial Zwecke.
http://www.visualdataflex.com/learn-more.asp?pageid=866

Hier noch ein paar Links:
http://www.dataflex-community.de/
http://www.dataflex.info/
http://www.dataaccess.de/

Taking a look into Google, I found myself more such tools like this:

http://www.sp4gl.com/

You will never see anything about windows when using these tools.
This is not a religious question. It does not mean that windows programming is forever obsolete.
It only says "There are projects out there which need different tools to come faster from A to B."

As an IT-Consultant, sometimes time is important.

Often when I use PB, the things I am doing are timecritical in terms of Runtime.
For example I did picture processing for a sawblade-manufacturing-machine.
The program has then 20 ms to analyze the picture from the camera and to react on the Beckhoff-Side of the programm.

In other cases, the program must not be that much efficient - but it must be ready as soon as possible.
Both cases need different Tols and different strategies.

We can now discuss in which group most programms today are.
After all, I would expect most htings beeing done with PB is non-GUI behind the Scenes stuff.

What do you think?

[Patrice Terrier]

I agree that people should consider seriously L5G tool like WinDev, but this sp4gl thing is definitly a NoNo.

Quick search on Google:

- sp4gl, 864 links
- WinDev, 2690000 links

If you look at their respective web site, you will see in a few seconds that there is no comparison

[Edwin Knoppert]

'One topic furter' you wrote:

"GDImage is an advanced graphic control using the latest technology.
It is a pure SDK 32-bit DLL working with ANY compiler including DotNET and WinDev."

Which is equally restrictive, not sure Chris or any selling developer (like me) waits on a topic like this?
(Not that i care one using a 'flamethrower' towards a product like PwrDev..)

Also:
GDImage is as far as i know a generic win32 dll and "It is a pure SDK 32-bit DLL" does not say it's a unmanaged library aka generic 32bit dll.
It's to be expected at some point your library can no longer work with newer .NET just as Chris's library may at some point for some reason.
(And not being to be able to update due dead or something like that)

[Patrice Terrier]

Sorry Edwin, but i do not understand your point here.

...

[Charles Pegge]

One solution to this dilemma of dependency is to develop tools that generate SDK source code. Users can then opt to embed it directly into the application or create their own DLLs. Savvy coders could also use it to generate a 'first draft'  then fine tune the generated code to their own needs. Then there is less burden on the tool developer to cater for every possibility in a 'black-box'.

[Bob Houle]

Personally I agree with Theo... when you need to develop a solution you look in your 'toolbox' and decide the best way to accomplish the task at hand.
It makes little difference to me if I have to include a DLL with my application, or whether it contains DDT code.

I usually choose 'PwrDev' because I can flesh out the forms almost instantly and Edwin has added a huge amount of 'commands' that simplify many things that a developer needs such as allowing you to create your own user-controls. His knowledge is my gain.

I agree it would be a bad thing if the developer were to stop developing your chosen product, but I'd still be able to use it 'as-is' forever.

--Bob

[Patrice Terrier]

Using proprietary Tools like EZGUI 4.0

--Theo
I would have entitled this new thread "Using third party addons" without any reference to a third party name, to avoid the possibility of misunderstood. Because I have much respect for Chris's and Edwin's work as well as others third party addon providers.

One solution to this dilemma of dependency is to develop tools that generate SDK source code.

--Charles
I agree with all your statements.

I shall be very glad to have a "screen designer" only, that would create a plain SDK code skeleton for me, like does Borje's  PBwinSpy.

And if this screen designer, along the use of moden components, would give me the possibility to customize the whole interface then it will become immediatly my tool of choice. And you know what, I woud have no problem to pay Euro 500 to get it, because it would realy fit my needs and save me hours, days, weeks, monthes, of hand editing.

...

[Theo Gottwald]

I agree it would be a bad thing if the developer were to stop developing your chosen product, but I'd still be able to use it 'as-is' forever.

I think that I am with Bob Houle here.
Also I would appreciate, if we get a discussion on all available third party tools here in the forum.
None of the tools is perfect, at least none of the tools i have used until now.

But those tools I have unsed until now have their place in my toolbox and will be taken out if it come to a project that fits to them.
After using EZGUI in my last project I have now a good idea where i can use it and make some sort of projects in - lets say half the time then without.

@Patrice:
Quick search on Google:

- sp4gl, 864 links
- WinDev, 2690000 links

Would you like to do this system with PB also? :-)
Besides that it is just another thing, WinDev compared to those 4GL Tools. Download the Freeware and you'll see the difference.

About the title, I have changed it. Actually I did not see any reason why Chris should not be Ok, if we discuss what we think of EZGUI.
Every producer of Software - that includes me, you and even Bob - has to some extend live with discussions about his product in the public.

And i want to make more such discussions. When I am through with my current project, I want to share my experiences using EZGUI.
Because i think i have now some experinces and can give hints to new users and talk about strong and weak sides.

What I can say now is, that - as i do not have own big libraries on windows tasks (other then the "commctrl32.inc"),
I am quite happy that I could use the libraries Chris built into EZGUI. It just saves time.

Also the support from Chris was really worth the price. Even if  I had not got the EZGUI and just bought the support he gave me, for this money I paid,
it would have been worth the price.

While today he wrote me, I should also post in the forum. Which I plan to do if I find good point.
My problem on this is, that if i pick out a single problem i see in EZGUI people who do not know the product may missunderstand this.

For example today i wrote Chris that in my opinion the Menu-thing is not yet round, because I need few lines of SDK-code to use it :-))).

Let me end with this EZGUI - code example:

 I can do a PopUp-Menu simple like this:
   

Code: [Select]

  S02="copy|paste|cut"
  EZ_DoPopupMenu S01, EZ_SetMouseXY(T03,T04), 9000, S02, "S"   
  ? "This will be called after the Popup dissapears"
Which is really easy. And the Popup is a modal window, this means that the Messagebox in my example code will only be shown after the popu has been closed.
Now where do i get the result of this Popup-Menü (e.g. the item the user pressed?). Its in the Windows Message Loop, with the code 9000 etc..
And this means that its not LOCAL to a procedure but spread everywhere in the code.

Under this condition (its a modal window), a user-friendly and local implementation would have been (Sorry for all those who love SDK and Message-Loops etc. :-):

Code: [Select]

R01=EZ_DoPopupMenu S01, EZ_SetMouseXY(T03,T04), 9000, S02, "S"   
  ? "The User pressed item "+STR$(R01)
Then its really easy and its LOCAL in sense that I can just use it in any sub without doing changes on other places,
but its maybe not more "windows-like".

PS: On the other side, I've just got a mail from Jose and he told me his opinion, that in a year, in which Obama gets president, everything may become better.
I hope we have the next generation tools out at this time, which will enable me to make all this stuff without studying on the university first :-).
I don't want to reinvent the wheel - its just a popup-menu, one line must be enough.

[Chris Boss]

One of the most important aspects of programming for many developers is speed of development.
It would be great if we all had the time to do everything at a low level, but many times speed of
development is critical. This is why components are used.

There is absolutely no difference between using a runtime DLL like EZGUI and GDImage.
Just because you make the source code available, it likely is of little benefit to the average
developer, since the code may be beyond their understanding. Source is meaningless if it
is not fully understood and a developer could spend months just trying to understand what
the source code actually does.

The key thing is how reliable is the component, whether a runtime DLL like EZGUI, a custom
control or OCX. VB'ers have been using components for many years and most of them don't
supply the source code with them. Not publishing source code is one way to protect trade
secrets and many companies will not do that.

The value of a software tool is not dependent upon whether it is 100% source code or that
source code comes with it, but whether it is well written and reliable.

I personally go to great lengths to make sure my software is reliable. I do a lot more testing
than many.

Also, I understood the need for the ability to expand beyond the core feature set of the runtime, so I
added a number of hooks into the core engine, so an experienced API programmer could expand beyond
it. If EZGUI doesn't do something exactly the way you want, you can create a hook into its internal
window procedure and message loop so you can preprocess messages before EZGUI does. I give you
access to all you need, so you can impliment standard SDK style code in your app, when something
else needs to be done, which is not currently supported by EZGUI.

It is this ability to be expanded upon (not a closed architecture) which allows programmers to go beyond
what the engine can do.

This means that EZGUI will never become obsolete, as long as the operating system is backward compatible
with for example XP.

[Theo Gottwald]

If we talk about source code.
The one thing i missed most in EZGUI is the Layout-Manager from Dominics Phoenix.

While I got a workaround from Chris (which I had to expand), this is a workaround,
It does not have the quality of the Phoenix "Layout-Manger" to resize Forms absolutely perfect.

But after all this Phoenix-Layout-Manager is also in a DLL. I don't have the source code, I don't need it.
The same is true for some of the controls included with the package.

The source code thing is important for projects where you want to end up with a single executable file.
There are such projects, and they can not be done with EZGUI (lets leave tricks aside here).

But other projects can have additional files and then I would agree with Chris here,
I personally do not see the big difference. We are talking from components.

We are talking from tools. I would like to get more discussion here in the forum,
which tools are helpful in which tasks. Thats what we have started.

I have posted some parts of EZGUI code in another post, maybe those who have not seen it before can take a look and verify that this is not far from SDK.

[Jürgen Huhn]

Hi there!!

The last Post to this Treat is a long Time ago, but I have to say..

I can see no Problem by using third party addons as long the use of them produce no Bug!
Everything has two Sides..

See the Possibility`s you have and what you want or need for your Application.

I`m personally prefer plain SDK, but my Life is to short to do all the work are already done in the third party addons!

For my Applications, I try to generate a plain SDK code skeleton with Tools like "PBwinSpy"!
Here I go the same Way like Patrice Terrier!
Coding in SDK-Style makes you free, and save your hard work for the Future.

Over the years I produced and collected a big pool of Code and Functions for the use with the WinApi.
In SDK-Style, means the Possibility to translate it to any other programming Language...
Also for a new Language in the Future!! Very important to realise it!!
The low level API is always the same whatever the language being used.

And also is my Experience with C++ and now even within PowerBasic, that plain SDK-Style is running faster and
produce less Errors in Memory (Paging Errors or in German: Seitenfehler). You can see that in the Taskmanager under
Processes(Prozesse). In the Listwiew there is the Column with this Name if it`s activated. If not, activate it in the
Menu under View (Ansicht-Spalten auswählen).

It`s a simple way to indicate the Quality of process programming, if you watch at the five Columns:

CPU-Time, Memory-usage, Max-Memory-usage, Paging or Memory-Errors and the count of Handles for the specific Process.

Most Reason for those Errors are Messages send from a Process they not reached the right or no Target.
Others depence on cleaning up Memory after finished process Actions(MemoryLeaks) or wrong Settings of Variables
or Data-Types,your Hardware and more...

The Point is, by using plain SDK you know exactly what`s going in your Programm!!
Less Errors and Messages who hit the right Target at the first Time, gives your Program
stability and Speed. An Error is a big Brake and can produce a chrash!!
And once you know what is going on behind the hood, then you can switch to another compiler ...

Two Sides, you have the choice...