Visual Design Considerations Part 3

[Steve Hutchesson]

Chris,

Much of the reaction you have received from the old timers is related to
using this forum in a way that it is not intended, it is finally a peer
forum among PowerBASIC programmers, not an advertising forum for
commercial developers hunting for clientele.

There are a number of after market vendors for PowerBASIC products who
regularly contribute to this forum who are very capable programmers and
would no doubt be capable af blowing their own trumpet in here as well but
they don't because this forum is not a spammers paradise, it is a forum
run by PowerBASIC for programmers who use their languages.

No-one denies you the opportunity to earn a living from writing
aftermarket software but the learning experience you have detailed on a
regular basis while developing the add-on that you wish to sell is not a
qualification to impose your particular commercial approach over and above
the other very experienced vendors who did not need to detail their own
particular learning experience in API style coding as they have been doing
it for years already.

That the managment of PowerBASIC recognise the value of aftermarket
vendors is reflected in the forum having a section for that type of
activity, the link for "Third-Party Addons" which is exactly the
advertising forum you need and where you think that your product is a
better written one or more suitable for a particular segment of the
market, this is exactly the place to do it.

Using the peer forum for blatant advertising is an abuse of that peer
forum and it is both unfair to the other vendor who do not do it and
unfair to the body of PowerBASIC programmers who contribute to this forum.
It is an interactive forum among programmers who assist each other in
technical matter as well as a place for different programmers to voice
their views on needs and preferences in the PowerBASIC product line.

As long as you inflict this abuse on the peer forum, you will keep
receiving flack from people who have very great depth in the area where
you are attempting to exert influence and trying to write them off as an
elitist API programming group as against your own approach will continue
to be seen as just another sales pitch in a forum that is not intended
for that use.

To drive the point in terms of interest, I do not sell after market
software for PowerBASIC and I have no commercial interest in this forum
over and above supporting a small software company that does it right. My
own commercial software is not for sale to the open market and the only
software I write that is available to PowerBASIC programmers is freeware
that I post on my own web site to assist other PowerBASIC programmers.

This forum is a place of goodwill extended between peers of similar
interest, I would hope that you can respect that and not use it as your
personal advertising space any longer.

[email protected]

[David L Morris]

Well said Hutch.

I am using your pstart11 and dbuilder examples and find them to be very useful as development tools. They are not complicated and provide a great start to effectively using the Win32API.

Additional controls, other than those easily available in the MS Dialog editor, can be added by using the API calls.

I think that some of the globals generated might be more appropriate to be generated as STATIC in the DlgProcess.


Regards,

------------------

[K Peel]

This must be the longest topic ever!

Whos going to start this time?

------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

[Chris Boss]

If I hurt anyones feelings I apologize.

I was content in discussing "future" Visual Design features for PB, but it seems rather than let me do that, others prefer to "imply" that my "product" is a farse. If others avoided "attacks" on "differing" concepts, it would be easier to discuss things like Visual Design in a peaceful atmossphere.

This is my last post on this subject.

------------------

[John Rayfield]

This thread has been 'interesting', to say the least. I've noticed that everyone has their own opinions as to how the user interfaces for Windows programs should be developed - some say that 'pure' API calls should be used (maybe with a resource editor), others say that DDT should be used, while others prefer using third party libraries. Even PowerBASIC (i.e. Bob Zale and company) has an 'opinion' on this, and the result of their 'opinion' was DDT.

Another interesting thing that I've noticed is that some who are more 'knowledgable' Windows programmers like using the API directly, maybe only using a resource editor for easier 'visual design' of the basic user interface. These particular programmers appear to feel that the Windows API is 'easy' to learn and use. Personally, as someone who has spent thousands of hours doing DOS programming (using PB/DOS), but very little time doing any kind of Windows programming, up until recently, I can't agree with this, at this point in time. Maybe, someday, when I have the time to learn more about the API, then I might agree that it's 'easy'. Yes, the API 'style' of programming is 'easy', as someone pointed out, since using API calls is not much different (if any) than using SUBS and FUNCTIONS with PB/DOS. But, it's not the 'style' of programming with the API that I would find 'difficult' - it's the sheer number of function calls, and the great number of possible constants and variables that go with these function calls, that I would find 'difficult' (and time consuming) to learn and use.

As a hobby, I'm an amateur radio operator (for over 25 years), with an Extra Class license (the top license). Learning electronics has always been 'easy' for me, kind of 'natural'. The tests that I had to take for my Amateur Radio license weren't what I would call 'easy', but they weren't really 'difficult', either. They just took time to study for. I also had to learn Morse code, besides electronic theory and government rules and regulations. When it comes to Morse code, I can now copy as high as 30 words per minute ('clean' code, computer generated). When I first started learning Morse code, over 25 years ago, just getting to 5 words per minute was 'hard' for me (as it is with most people). Now, I find that copying code at 15 to 18 words per minute is very easy (it's almost too slow for me). Yet, for someone who doesn't know Morse code, they would say that learning even 5 words per minute is VERY hard (people DO say this, all the time).

Now, since I feel that Morse code is 'easy' for me (and others who have learned it), then it surely must be 'easy' for others (who haven't learned it), right? Not at all. Again, just because something is 'easy' for me, that does NOT make it 'easy' for someone else.

I think we all need to keep in mind that everyone is at different 'stages' of learning - thus, some will find that using the API is 'easy', while others will find that it's not 'easy' for them, preferring instead to use DDT or third party libraries and code generators to 'ease' the development of Windows programs. While I find Morse code 'easy', I'm careful that I don't 'put down' those who find it difficult - I would hope that those who are more knowledgable of Windows programming would show me the same 'respect'.

John Rayfield, Jr.


------------------

[Siamack Yousofi]

Gentlemen!

I have been thinking (I know! Don’t laugh ). Perhaps we should all take a deep breath and start thinking outside the square.

You see uncle Bill’s “personal wealth” alone is more than 1000 years worth of PB’s annual revenue! He “owns” more than 60,000 developers including 5000 crack programmers who wrote the darn thing in the first place! He has 5 million VB programmers to milk. He also likes to play as Chief Architect.

So I am wondering why we are going to Bob and pointing at VB when we should really be going to Bill and pointing at PB. If you say that Bill could never make VB produce executables like PB, then I put it to you that Bob would never be able to do the reverse either (my personal opinion of course).

So let us re-group. Those who want VB interface with PB output start pushing Bill. The rest can start thinking laterally to find an acceptable alternative. We shall all benefit irrespective of whoever gets there first!

Siamack


------------------




[This message has been edited by Siamack Yousofi (edited February 18, 2000).]

[Knuth Konrad]

My personal summary so far from this thread(s):

- A Visual Designer will be a very welcomed tool, no matter if PB realeases it or a 3rd Party vendor
- While one group prefers SDK style "output", the other votes for "DDT"

A lot of good arguments have been posted for the SDK style. I personally tend to vote for DDT code. I did choose Basic as "my language" because it eases the process of developing an application. I'm able to concentrated my efforts on solving tasks my application should fullfill rather than how to sort an array or put together the GUI for my app. PB has allways fullfilled my needs in that way that they gave my a great set of language features. Be it in the area of string handling (the best I've seen so far), array handling, TCP/IP...and finally DDT. The power is there (in the compiler). Now I need a tool that will help me to use this power: a Visual Designer that let's me visually (=fast) design my GUI and produces DDT code.
There has been some argue about such a designer creating bloated code. This is IMHO an important argument. And I tend to believe that an SDK designer, although it might produce better "general purpose code" - even for other languages, will create code which is more bloated than a designer that is specialized on DDT.
Another point is: I allways try to achive my programming goals with the features/functions that the compiler/language is offering me. While SDK uses third tools (the Win API in that case) to accomplish that task, DDT is offered by the compiler. I no, of course, that DDT internally calls the API as well, though...

Bottom line: A specialized tool does it's job better than a general purpose tool. While you can use Word as a HTML editor, Homesite, Dreamweaver and the like do a better you on HTML. Hence, DDT not SDK

Knuth

------------------

[Michael Meeks]

Comparing PB to any other M$ language, is a lost cause!

PBDLL does it better, faster and more efficient! I too, as all of you have, a wish list. If PB never changed another line of code, I'd still be happy with PB using DDT, API and ASM. (You only get better, when you use it.)

Although I have expressed my opinion about PB, some good, some bad, and as we express our opinions, I hope that PB will extract the wisdom from all views and ignore our visual cheap shots and visual ignorance.



------------------
mwm

[Jim Seekamp]

I've also noticed something from this thread:

Some users are trying to learn Windows before they program in it,
while others want to program in it without learning it. I am
of the opinion that the people who complain about the Windows
API being "too complicated" or "too large" or whatever, decide
that if you're going to program in Windows, LEARNING TO PROGRAM
USING THE API IS NECESSARY. All the shortcuts come down to calling
Windows API calls anyways, so WHY NOT SPEED UP YOUR APP and make
it as internally "Windows" as possible?? Does anyone go into a
profession without spending time learning about the basic foundation
of that profession?? The basic foundation of Windows is the API.
Programming in Windows without knowing the API is like a person
operating on someone without going to medical school. If you
don't know what messages your app is sending to Windows to complete
a task, or you don't know what messages Windows is sending to your
app, that's the Doctor not knowing what is causing his patient to
suffer. If all we're looking for is shortcuts, try to imagine
your Doctor looking for shortcuts to knowing the facts about the
operation he's about to perform on you!
Even a resource editor creates an .RC file, so you can see which
properties and attributes are being used after you visually create
the resource; this 'Visual Design' can be taken far beyond that
point, and when it gets to where you don't even know internally
what it's doing, that's scary.
How about a good resource editor?

My $0.02



------------------
Jim Seekamp

[Jim Padgett]

I only want to be able to design my GUI easliy. I prefer one executable, but small runtime dll 's are OK.

I don't want to have to spend a lot of time to do things that are simple in concept, but painful in actuality. Like placing different colored text on the same line in a text box. These things were simple with dos using esc codes, but now are a pain in the rear in windows.

I have bought PGen, and EZGUI . Each has weaknesses and leave something to be desired.

I have also used some of the other code generators and I can't fault any one of them above the other.

At this point I think I would be happy with a bunch of INC files to let me do what I want without the tedious effort required to just make my apps look pretty let alone function properly.

I guess static librarys would fill the bill here though.

I guess Petzold's statements about you might as well learn API's sooner or later you will have to any way is going to hold true.


------------------

[Knuth Konrad]

Originally posted by Jim Seekamp:

All the shortcuts come down to calling
Windows API calls anyways, so WHY NOT SPEED UP YOUR APP and make
it as internally "Windows" as possible??

Because I don't need to speed up my apps. They're fast enough. In fact, most of the time an application idles around and waits for user input. I want to speed up the DEVELOPMENT time - to be more specific: the time I need to create a good looking and intuitive to use GUI.

If all we're looking for is shortcuts, try to imagine
your Doctor looking for shortcuts to knowing the facts about the
operation he's about to perform on you!

The doctor does not look for shortcuts about the operation (I hope so, at least). But he did look for shortcuts for the diagnostic part of his job. While in the old days he had to search all over his books, spending hours to find out what illness it is he needs to cure. He nowerdays can pinpoint the disease within second when using a medical database. That gives him more time to spent on the REAL important part: the operation.

The same goes for development. Why spent endless hours to design a GUI when you know this can be done in minutes? I prefer spending this time with programming rather than counting pixels/dialog units.

Knuth


------------------

[Mike Doty]

Chris,
EZGUI has helped me understand a lot of things
and I plan on using it. You need your own forum.



------------------
mailto:[email protected]

[Jim Seekamp]

Quote: (By Knuth)
Because I don't need to speed up my apps. They're fast enough. In
fact, most of the time an application idles around and waits for user
input.

OK... let me re-state; Why not have your source cose reflect what is
really going on in Windows instead of fabrications based on the
middle-man libraries that end up doing the same thing.

Quote: (By Knuth)
I want to speed up the DEVELOPMENT time - to be more specific:
the time I need to create a good looking and intuitive to use
GUI.

That's what a resource editor is for, and that's why having one for PB
would be nice.

Quote: (By Jim)
If all we're looking for is shortcuts, try to imagine
your Doctor looking for shortcuts to knowing the facts
about the operation he's about to perform on you!

Quote: (By Knuth)
The doctor does not look for shortcuts about the operation
(I hope so, at least). But he did look for shortcuts for the
diagnostic part of his job. While in the old days he had to
search all over his books, spending hours to find out what
illness it is he needs to cure. He nowerdays can pinpoint the
disease within second when using a medical database.

The doctor can look things up all day long, but if he never went
to medical school and learned the API so to speak, he's still not
going to have a successful operation.

What is the big deal?? Just keeping a copy of the API handy is
enough to start with; why is that so overwhelming and
"time-consuming" to people? In the long run, the knowledge
will do more good and make for faster programming because
of familiarity. The market value of a programmer goes way up
if they have a good knowledge of the Windows API. Every time
something new crops up, you can just consult a reference, find
the necessary calls, and now that's familiar too.

The statement that API programming is time-consuming is always
made by people who are not used to doing it. The only way to
get used to doing it is to do it.


------------------
Jim Seekamp

[Ian Cairns]

I agree with Jim about the resource editor. Most of the preliminary work in my programming seems to have to do with dialog boxes. There is a crying need for a PB resource editor that can work with the Newer and Future controls.

With this, I would also like to see the option of generating an Outline file that would contain for each dialog/menu/status Bar/etc, a Function template referring to each Control by its Type and Handle. It should also generate an Include file of the Symbol table, grouped by Function.

Apart from this, I see the need for including Static Libraries with "Smart Linking". It can't be an easy thing to do, or we would have had it already. This is a Compiler issue that has to be addressed by the PB company. The other is a programming issue that a third-party vendor could address, but which (IMO) should be done by PB.

(another nickle from the Canuck)

------------------
[email protected]

[John Rayfield]

>I want to speed up the DEVELOPMENT time - to be more specific:
>the time I need to create a good looking and intuitive to use
>GUI.

>The same goes for development. Why spent endless hours to design
>a GUI when you know this can be done in minutes? I prefer spending
>this time with programming rather than counting pixels/dialog
>units.

Personally, I agree with the above.

I have a friend who's an engineer and programmer with Allied Signal. He develops software for testing the avionics equipment that they build. He told me that they don't want to have to spend a lot of time on the GUI interfaces. In fact, he said that once they finish a GUI interface, they like to 'forget about it' and spend their time on the routines in the software that do the actual 'work' (testing the avionics equipment). He said that they use third party tools (including third party libraries), and that he has NEVER used the Windows API. Also, he said that most of the other programmers there feel the same way that he does.

I found this interesting, coming from a 'professional' engineer and programmer, working for a VERY large high-tech company.

I guess some programmers can use third party DLL's and still keep their jobs.

John Rayfield, Jr.


------------------

[jcfuller]

The statement that API programming is time-consuming is always
made by people who are not used to doing it. The only way to
get used to doing it is to do it.

How true, how true.

If you primarily use a RAD tool and then NEED to use the API
for a particular reason, the time wasted trying to figure it out can easily
negate any time saved using the rad tool.

James


------------------

[Jim Seekamp]

John Rayfield; I agree wholeheartedly as far as needing to
create dialogs and the graphic end of an app, which is why PB
needs a good resource editor. I was referring to using the
Windows API with it's format of callbacks, etc instead of the
VB middle-man library approach where there is no sign of the
existence of a callback function, some WinAPI functions cannot
even be used, and the source layout has no resemblance to what
is really going on while the program is executing.
I'm all in favor of the resource editor that will create the
visual design. Any developer would be I think; as long as it
creates the .rc file so the resource can be edited easily also
for changes in attributes, etc.


------------------
Jim Seekamp

[Jeffrey R. Radue]

I have written a couple of very large programs in VB over a period of several years. Both of these programs are full featured and contain dozens of dialogs. I decided to use VB because it was very easy to generate GUI elements. I quickly found out that VB was very poor at time critical routines and graphics. Because of this, almost all of my program code is API based except for the dialogs. After purchasing PB I was very excited by the idea of porting the applications over. Because there is no itegrated visual designer with PB, I am facing literally hundreds of hours generating GUI code to replace the VB forms I am currently using. This must be an issue with alot of people.

I understand how to use API code and DDT to generate windows and dialogs, and I do not want a visual designer to avoid learning programming. I am a professional engineer with programming experience in C, fortran, pascal and of course BASIC. However I dread spending all the time to manually convert my current code when a better solution should be available.

Perhaps some people believe that they are better programmers or will generate better applications if they write programs typing in every SendMessage call. I personally feel that is ridiculous. Time is money these days, and if you are an individual programmer trying to keep pace with the ever changing software market, then the last thing you need to do is waste time setting up a dialog.

My final vote is for some sort of visual desinger which generates API or DDT code which can be compiled by PB into a EXE or DLL. I would not like to see an add-on DLL or OCX which does the work during runtime.

Thanks again,

Jeff



------------------

[Andy Anderson]

I'm inclined to agree with some of John Rayfield's observations.
(John doesn't know it but we're neighbors being that we both
live in the Springfield, Mo. area.)

My wife and I have programmed for.......well, a long time. We
started on machines and languages that no longer exist
except in museums, duly made our way through the IBM midrange
era, migrated to DOS PC's and then to Windows. Although not
expert, our knowledge of the Windows API is passable.

Yet, we avoid using the API whenever possible. Why ? First,
the API is like another language and why learn yet another
one unless necessary ? Self enhancement is nice but our wallet
would rather have us spend the time on applications. They make
money. Secondly, the API changes from OS to OS, from 16 to 32
bits and you may find yourself reworking things extensively
with 64 bit Windows 2???. I'd rather let that be the language
vendor's worry.

In my mind, the language itself should be sufficient with the
API reserved for special things like the interrupt calls were
in DOS. This is most evident when dealing with a GUI. It takes
us 400% (at least) the time to develop Windows apps compared
to DOS. This is primarily due to inadequate GUI tools. Visual
Basic is probably the best in this area which is why it is so
popular despite its' many shortcomings.

If somebody like Chris wants to develop an add-on that (shudder)
shields me from the API and allows me to concentrate more on what my program accomplishes rather than how to produce its' appearance to the user, then I'm all for it. I'll judge Chris' and anyone else's product on how efficiently and effectively it accomplishes its' intended purpose.

As far as the issue of DLL dependencies, in today's computing
environment, the alternative is giant Delphi like exe's. There
are over 200 exe's in one of our systems. They all use a file
access DLL written in PB/DLL. I have tinkered with and adjusted
this DLL frequently without having to recompile the programs
that use it. I vote for the DLL over static libraries.

Andy Anderson
[email protected]


------------------

[Lance Edmonds]

Jeff said:

My final vote is for some sort of visual desinger which generates API or DDT code which can be compiled by PB into a EXE or DLL. I would not like to see an add-on DLL or OCX which does the work during runtime.

This is exactly what PowerGEN does... it create (SDK style) API code ready for compilation. While it does not currently do DDT, it fits your bill exactly as you request. Rather then reinventing the wheel by including a proprietry resource editor, it uses scripts created with DLGEDIT, Visual Studio and Resource Workshop.

The tool you want most is here already


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>