No announcement yet.

An alternative approach to GUI!

  • Filter
  • Time
  • Show
Clear All
new posts

    <<In fact, many of clients are now using my program, because of <<your software, which I'm unlimited in what I can do with HTML <<& PowerBasic together.
    Thanks for the nice words. Please note that the demo was a joined effort by Patrice Terrier and me. Patrice is the author of the WinLift skin engine while the JA COM/PB 2.0 was used to ActiveX enable the PB/DLL form.

    <<I now label my html (dll's) of what the content is. No reason <<to add this to my fast exe file.
    Also, the WebBrowser demo can be used to display very different types of documents: HTML pgaes but also Word files, Excel spreadsheets, Visio drawings ...




      Hi Siamack et all

      I finally got round to taking a first shot at implementing an I/O driven GUI server. Since there are several files and some sparse documentation, I've uploaded the zip file to my server.

      Look at the beginning of the thread to have a look at the discussion which prompted this prototype.

      Download: and unzip. Run sample.exe: it will show you the documentation and some example code.

      Comments, flames and gripes are welcome


      [This message has been edited by Florent Heyworth (edited March 05, 2000).]



        Thank you and well done! This is exactly what I had in mind!

        Although I happen to be the one who started this thread, the idea had already crossed the minds of a number of participants including you.

        The example you have posted proves that the concept is a viable alternative indeed. Browsers will only get better and more versatile with each new release. In fact we may have a browser as a stand-alone “Operating System” of sorts for dedicated Internet devices in the not too distant future. So where appropriate, why not use the browser and HTML/XML as our GUI platform and Powerbasic as the engine?

        This is particularly useful in Linux. None of the Linux GUI options are native to the OS. The browser is the best bet for compatibility on Linux and when PB/Linux is released this model would be a potent alternative.

        You asked about licensing. Obviously, you must receive compensation and recognition for you work. However, if a number of people in this forum alone had independently thought about this model then chances are many more in the world at large are also working on this. The model can be implemented in any language and is reasonably straightforward. So putting the code in public domain and using the credits and recognition may indeed pay better dividends.

        IMHO Powerbasic should seize the opportunity and implement this model at the language level. Browsers have APIs too. So why not extend the DDT to cover Browser API’s also and make this model native to the compiler! Its implementation is certainly less complicated than Windows native GUI and well within the excellent expertise of Powerbasic development team. If done in a timely fashion and before everyone else, this will put Powerbasic in a position of leadership.

        I look forward to the enhancements you have planned.

        Thank you again.



        [This message has been edited by Siamack Yousofi (edited March 06, 2000).]


          Quick question...

 send a file to the browser, piece of cake right? Yup...

          So lets say the user wants to input something BACK to the program....that may require you to re-launch the browser and use port 80, but what if you are running on the machine with another webserver already?
          How does the browser talk back? Is it for one way communications only? Awesome idea, very very good...

          And how does IE communicate BACK to the main program in general terms without using OLE???

          Front Page has a tool much like this, just a script, like anything else, and it saves a JET database file I guess much like another product I work with....


          mailto:[email protected][email protected]</A>
          Scott Turchin
          MCSE, MCP+I

          True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi


            Hi Scott

            I'm not sure I understand what you mean with
            So lets say the user wants to input something BACK to the program....that may require you to re-launch the browser and use port 80

            Per default (in the sample program) the server waits on port 80 - you can ask it to wait on another port though. Browsers per default want to talk to port 80 but you can also steer that in your html files. Let's say you want your browser to talk to a server waiting on port 8088 you would do something like: http://localhost:8088/hello

            The standard way to get input back from the browser is to use the "POST" mechanism:
            <FORM ACTION="http://localhost:8088/mycgi" METHOD="POST">
            <INPUT TYPE="text" NAME="User Entry">
            <INPUT TYPE="submit" NAME="SendIt" VALUE="Click Me">

            The browser then makes a request to the server telling it that it used the "POST" method. The server parses the header sent by the browser and makes it available to environment variables such as: REQUEST_METHOD="POST", etc. The cgi can then use this information to process the user input and sends back the result to the server which returns it to the browser for display.

            As Lance likes to say: "clear as MUD"?



            [This message has been edited by Florent Heyworth (edited March 08, 2000).]


              ..The idea of letting IE and HTML/XML files be the
              GUI user interface is very interesting. Has anyone
              completed a simple appication using this technique
              that they can share with us?
              ..Did you know the there is a compiler available
              for HTML/XML file? If not, check this out:
              By compiling your HTML/XML files your program will
              be better protected from unauthorized changes.

              mailto:[email protected][email protected]</A>


                Hi Martin

                some while back I started working on a PB web application server
                to do just that and I posted a working example. While working
                on my Listener application I realised that what I actually needed
                was a multi-threaded server since I didn't want to restrict
                myself to just servicing one user and hanging in long running requests.

                I threw my whole design out of the window and started re-working
                it as a full-fledged high-performance web/application server.

                To address the performance issue I decided to go with I/O Completion
                ports which is essentially a kernel I/O threading model which gives
                very high throughput - the downside is that it's only available
                on NT and higher.

                Since my goal was to go beyond just a GUI server this hasn't bothered
                me. It's been a lot of work - I'm just now completing my first
                application for a large music store in Switzerland.

                Here are the features of the server:
                - Requires NT and higher
                - uses very fast I/O completion port model
                - uses thread pools
                - support for SMP
                - supports application namespaces
                - supports customisable settings per application/namespace
                - allows to define routines which should be called before
                delivering documents (to check security and all that)
                - Own api (no CGI) which allows PB and other DLLs to get loaded
                by the server - the server then calls exported functions according
                to URL Get/Post requests.
                - Uses SEH structure exception handling for robustness
                - Comprehensive API:
                - Datetime functions
                - ODBC wrapper functions
                - Associative dictionary functions
                - CGI/cookie handling functions
                - fast inline assembler string functions
                - XML parsing functions - supports well formed XHTML but not
                - secure hashing functions

                This is still a work in progress. I have yet to add a DOM extension
                for XML parsing, SSL and TLS support for security and write include
                files for PB, C and maybe Delphi.

                I'll probably rework the API as well to make it more user friendly
                as well as exposing the server as a C++ class...

                Notwithstanding, my first customer should be installing the first
                app to go with it so I may be able to show you an example real
                soon now (but don't hold your breath

                If PB people are interested I may decide to release the server
                and API - on what terms etc, I still haven't decided.





                  Originally posted by Siamack Yousofi:
                  Ladies and Gentlemen

                  As Black Adder used to say, "I have a cunning plan” and thought you might find it useful.

                  Unfortunately I cannot post any code as my work belongs to my employer. However, I came up with the original idea before he hired me. Since he refuses to look at Powerbasic then I guess it is his loss. <IMG SRC="">

                  I will explain the concept in broad terms and then you are on your own. Some feedback would be nice.

                  When speed of the GUI is not an issue we can use a web browser as our GUI front-end. Here is how…

                  We write all the application's logic in Powerbasic and compile it into an .exe. When the plication is invoked, it will show a very simple Dialog/Splash screen (simple stuff in DDT). If necessary, we ask for username and password here. Then the program will detect and show the IP address of the PC (in large friendly letters ). The program then invokes the browser and “serves” a “default.html” file to the browser and minimises itself. What is in the browser is our application’s main “screen”.

                  The program then enters the main loop and monitors “Port 80” for user interaction. The entire user interface is handled through HTML pages and a browser. The program either dynamically builds the HTML pages in memory or retrieves them from the disk and modifies them through text substitution.

                  The advantages are many. Here are some of them…

                  1. We do not need to worry about Windows messages and callback functions any more.
                  2. We do not need to learn DDT or API and the complexities of Windows GUI. Just HTML/XML.
                  3. As HTML and XML standards evolve we can do better and better user interfaces.
                  4. Our applications can be content driven.
                  5. We can change the user interface very quickly.

                  Of course this is not appropriate for every application and there are many disadvantages too .

                  Obviously performance is a major consideration, but as someone suggested before, many applications sit idle most of the time while the user or the database back-end do their bit.

                  This option will give us total independence from Windows native GUI and can be used with any language. PB/CC and PB/DLL are obviously among the best.

                  The fact that these programs can also communicate with other similar programs through “Port 80” over any TCP/IP connection should open interesting avenues for distributed computing.

                  If the concept is successful then Bob Zale and his team can consider introducing native support for this model at the compiler level.

                  I know this sounds quite revolutionary and GUI elements in a browses are not as mature as Windows native GUI. But lateral thinking never hurt anyone.


                  [This message has been edited by Siamack Yousofi (edited March 06, 2000).]




                    I'm intrigued with your idea about using a browser (as an
                    alternative to learning Windows programming) to allow a
                    PB DOS program to run in a Windows "like" environment.

                    Could you please send me your email address; I'd like to discuss
                    this with you ...

                    Email: [email protected]




                      Cool idea...

                      What about using a Flash as the front-end user-interface and
                      have PBCC in the background feeding all the info to flash.

                      Macromedia has a program call Generator (a small version ships
                      with Flash 5) that leaves place holders in Flash movies for
                      information that PBCC could possibly fill.

                      I don't know enough about the ins and outs of Flash and Generator
                      to know if this would be possible or if it makes sense.

                      I use Flash for website opening screens and it's really neat. One
                      may be able to use it to make very interesting dynamic user interfaces.


                      Rodney at Wirtz dot com



                        Technically any browser-based application should work. The concept is
                        to use a light-weight local web server, like the one Erik Olsen posted
                        in the source-code forum some time ago, and extend it with your application's
                        logic while using the browser as the front end.

                        Florent have done some excellent work in this area and there is a link
                        posted a few messages above.


                        P.S. You can download Erik's code from the download area.

                        Look for


                        [This message has been edited by Siamack Yousofi (edited June 13, 2001).]