Rodney
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.
Siamack
P.S. You can download Erik's code from the download area.
http://www.powerbasic.com/files/pub/pbwin/inet/
Look for http.zip
------------------
[This message has been edited by Siamack Yousofi (edited June 13, 2001).]
Announcement
Collapse
No announcement yet.
An alternative approach to GUI!
Collapse
X
-
Siamack,
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...
------------------
Leave a comment:
-
-
Siamack,
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 ...
Fred
Email: [email protected]
------------------
Leave a comment:
-
-
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="http://www.powerbasic.com/support/forums/supergrin.gif">
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.
Siamack
[This message has been edited by Siamack Yousofi (edited March 06, 2000).]
------------------
Leave a comment:
-
-
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
HTML
- 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.
Cheers
Florent
------------------
Leave a comment:
-
-
..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:
.
http://www.webcompiler.com/product.html
.
By compiling your HTML/XML files your program will
be better protected from unauthorized changes.
------------------
Marty
mailto:[email protected][email protected]</A>
Leave a comment:
-
-
Hi Scott
I'm not sure I understand what you mean withSo 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">
</FORM>
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"?
Cheers
Florent
[This message has been edited by Florent Heyworth (edited March 08, 2000).]
Leave a comment:
-
-
Quick question...
..you 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....
Scott
------------------
Scott
mailto:[email protected][email protected]</A>
Leave a comment:
-
-
Florent
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.
Siamack.
------------------
[This message has been edited by Siamack Yousofi (edited March 06, 2000).]
Leave a comment:
-
-
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: http://www.radbit.com/code/listen.zip and unzip. Run sample.exe: it will show you the documentation and some example code.
Comments, flames and gripes are welcome
Florent
[This message has been edited by Florent Heyworth (edited March 05, 2000).]
Leave a comment:
-
-
<<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 ...
Philippe
------------------
Leave a comment:
-
-
Siamack Yousofi
Philippe Monteil
Yousofi, your idea (which I also have been working on) is right on que!
Monteil, when I purchased your skin, I had asked you for the source to the html/help file. This engine of yours does exactly what Siamack was talking about. 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.
If others out there don't know what I'm talking about, contact
Philippe Monteil and ask for a demo of the skwebber application. This is a simple example, but gives you an idea what some of the possiblities are! I can now create html files as I need them and delete them when I'm done, using a simple PB DLL file. I now label my html (dll's) of what the content is. No reason to add this to my fast exe file.
As far as I'm concern, Philippe has already done the work for me. All I have to do is design my html pages. Couldn't haven't any better than this!
My $.02 worth!
MWM Consulting
------------------
mwm
Leave a comment:
-
-
Originally posted by Siamack Yousofi:
James
Thanks for the tip. I shall have a look. Where can I find rsrc utility?
Siamack
www.capital.net/com/jcfuller/rsrc.zip
------------------
Leave a comment:
-
-
James
Thanks for the tip. I shall have a look. Where can I find rsrc utility?
Siamack
------------------
[This message has been edited by Siamack Yousofi (edited February 27, 2000).]
Leave a comment:
-
-
Originally posted by Siamack Yousofi:
I forgot to mention before but Greg Turgeon posted the code for a utility that allows us to embed any file in an EXE or DLL
Saves you having to recompile the bas source evertime you need changes.
James
------------------
Leave a comment:
-
-
florent
i see your point about the complexity of the html/javascript page negating the advantages of this model.
we are all so used to windows that it is natural to think in windows gui terms when we design web pages. if we think within html limits then may be a simpler interface could do the trick for certain applications.
after all the real advantage of a browser interface is its "content-driven" paradigm. many web designers seem to have forgotten about this capability and are carried away with fancy graphics and special effects.
i am very grateful to you for trying out this idea. obviously, it will not be a universal method of gui design but if it proves useful even for specific applications where user interaction is minimal then we have an alternative solution.
since the application can send the data to the browser without waiting for a "request" then we have some sort of "push" technology right away. it may also prove more useful on linux where the os and its many gui front-ends are in a constant state of flux.
i forgot to mention before but greg turgeon posted the code for a utility that allows us to embed any file in an exe or dll
i used it in conjunction with eric olson's http server and created an "instanet" where web pages are linked into the executable and are modified through text substitution just before they are served. text substitution is in the same way eric has done it in his example. the result is a single exe containing both the server and content that you can run from the floppy. nothing needs to reside on the pc. combine this with the model i am proposing and we have some very clever stuff.
i think no matter what the outcome, it is worth a try. thank you again for investigating the idea.
siamack
------------------
[this message has been edited by siamack yousofi (edited february 26, 2000).]
Leave a comment:
-
-
Hi Siamack
FWIW I've been exploring the possibility of using a browser as a UI component. I've got a half-clobbering example of an app - the PB app is implemented as single-threaded concurrent server using a "select" loop ISO of Eric's HTTP server. When it's a bit further along I'll be happy to post the code.
However, even at that early stage many problems become apparent: using a browser (IE is the most advanced at the moment) does not IMO simplify UI design. To get any non-trivial UI interface together requires a thorough grounding in HTML as well as a good working knowledge of Javascript/Jscript. The interaction between the page elements and the PB server app rapidly become complex.
Implementing some kind of CGI is straightforward - but updating parts of the page ISO just presenting a new page requires using (I won't mention XML data islands or other forms of data binding) numerous frames which again complicates UI design.
Additionally, Microsoft has been extending IE so that it is becoming an application development tool in its own right. As an example see the code below. Cut and paste the code and save it to a file with an HTA (HTML Application) extension as in "test.hta". You can provide an icon in the current directory so that you'll see an application icon. Test the code by invoking it from the command line: test.hta
Note that this example requires IE5 (might work with IE4)
Code:<HTML> <HEAD> <TITLE>Test Application</TITLE> <HTA:APPLICATION ID="Test App" APPLICATIONNAME="myApp" BORDER="thin" BORDERSTYLE="complex" CAPTION="yes" MAXIMIZEBUTTON="yes" MINIMIZEBUTTON="yes" SHOWINTASKBAR="yes" SINGLEINSTANCE="yes" SYSMENU="yes" VERSION="1.0" SCROLL="no" ICON="Gnome.ico" > </HEAD> <BODY> This is a simple HTML Application. <BR> <BUTTON onclick="self.close()">Exit</BUTTON> </BODY> </HTML>
Implementing the PB server side you basically get the following beast: a lightweight server serving documents/data on the client side. The client does not need a webserver. You can make sure that the HTML page requests data using a particular port, etc..
In essence you get a lightweight, personal application server. Again is it worth the trouble when you can essentially install the light version of "Cold Fusion" or some other app server on your client's computer and have a lot more functionality "out of the box" - if you need speed you can always spawn off a PB app to deliver the information.
My personal opinion is that it's not worth the effort, although, as I said, I will post the prototype as soon as it's ready for human consumption.
I think that the way to go is with a description language, layout designers, ideally using XML - which can be used as a common language by all Visual designers.
Stay tuned
Cheers
Florent
------------------
Leave a comment:
-
-
Florent
Your idea for using XML as a resource definition language is brilliant. You did suggest it in the "visual design tool" thread and IMHO it should be taken seriously by those who are thinking of developing such tools for Powerbasic.
In fact future resource editors would possibly create resource scripts in XML instead of the current plain text format.
However, my suggestion at the beginning of the current discussion was to offer an alternative technique that we could use right now with what we have.Once the concept is proven as workable, a logical path for future development would present itself.
It is possible to take Eric Olson's "HTTP server" example and modify it to do what I am suggesting.
It just needs someone with a bit of spare time to investigate the practicality of the concept.
Siamack
------------------
[This message has been edited by Siamack Yousofi (edited February 26, 2000).]
Leave a comment:
-
-
Print to a printer, with headings repeated on each page.
Regular reports are sort of dull, html tables can use
proportional fonts with numbers right justified so they line up.
------------------
Leave a comment:
-
Leave a comment: