Announcement

Collapse
No announcement yet.

Visual Design Considerations Part 3

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Visual Design Considerations Part 3

    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]
    hutch at movsd dot com
    The MASM Forum

    www.masm32.com

  • #2
    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,

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

    Comment


    • #3
      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>

      Comment


      • #4
        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.

        ------------------
        Chris Boss
        Computer Workshop
        Developer of "EZGUI"
        http://cwsof.com
        http://twitter.com/EZGUIProGuy

        Comment


        • #5
          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.


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

          Comment


          • #6
            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).]

            Comment


            • #7
              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

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

              Comment


              • #8

                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
                mwm

                Comment


                • #9
                  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 Seekamp

                  Comment


                  • #10
                    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.


                    ------------------
                    Warped by the rain, Driven by the snow...

                    jimatluv2rescue.com

                    Comment


                    • #11
                      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


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

                      Comment


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



                        ------------------
                        mailto:[email protected]
                        How long is an idea? Write it down.

                        Comment


                        • #13

                          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
                          Jim Seekamp

                          Comment


                          • #14
                            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]
                            :) IRC :)

                            Comment


                            • #15
                              >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.


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

                              Comment


                              • #16
                                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


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

                                Comment


                                • #17
                                  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
                                  Jim Seekamp

                                  Comment


                                  • #18
                                    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



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

                                    Comment


                                    • #19

                                      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]


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

                                      Comment


                                      • #20
                                        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>
                                        Lance
                                        mailto:[email protected]

                                        Comment

                                        Working...
                                        X