PBCC GUI's ???

[jcfuller]

I notice a number of PBCC Graphics window code, simulating standard Windows and controls, and I have
to ask Why? Are the programmers unaware you can create full blown GUI programs using a number of methods:
1: Standard CreateWindowEx calls
2: Use a Resource Editor to design your screen with only one line of code for display.
3: Use My Runtime Dialog code posted in a number of places on this forum.
4: Use my SDKSERV code located the source code forum.
source will be released eventually and compileable with PBCC

Is it for the cool retro look?
Maybe your Suzy is even slower than MCM's?

I am curious.

James

[Michael Mattias]

Best guess:

Creating a "GUI Look and Feel" using the GRAPHICS commands is "familiar" in that you follow the same logic you would creating MS-DOS "graphical" applications.

That is, the programming model is still procedural ; CreateWindowEx/CreateDialog programming requires you at least learn something about event-driven programming technique.

[Dale Yarker]

5. PBWin

[Michael Mattias]

>Maybe your Suzy is even slower than MCM's?

BTW, Susie (that's the way my "Real Suzy" spells her name) is not "slow" at all. When I watch her work with the software I've created, I am amazed at just how quickly she gets things done.

Her job is entering customer orders.. and even though I have no need of their particular items (auto parts), I'd order from them if I knew she would be entering MY orders.

Susie does not, however, have any training beyond "click here to do this" - because her employer utilizes an outside resource specifically to make it possible to enter those orders with that one click.

MCM

[jcfuller]

I don't believe I did any text based input screens with PB.
I did do one large project for GE using QB45 and a third party text windowing library but with PBDos 3.0 I used my PBGUI for data input.

James

[Chris Holbrook]

3: Use My Runtime Dialog code posted in a number of places on this forum.
4: Use my SDKSERV code located the source code forum.

I will read these and hope to to discover the error of my ways.

[Chris Holbrook]

3: Use My Runtime Dialog code posted in a number of places on this forum.
4: Use my SDKSERV code located the source code forum.

James, the above used as search terms combined with your name yield no results. Please post links.

[jcfuller]

Here is the link for the Run Time Dialogs:
http://www.powerbasic.com/support/pb...t=38953&page=3

I don't think the code posted for the server access as posted will work with PBCC so I'll attach a PBCC specific one in this thread.
And there is no error of anyone's ways if you did not know there was an alternative.

James

[jcfuller]

Here is a working example using PBCC with my GUI Com server.

James

[Chris Holbrook]

Here is a working example using PBCC with my GUI Com server.

Thanks James, very impressive stuff in its own right.

Going back to your original question, there was a thread http://www.powerbasic.com/support/pb...t=38632&page=2 in which I suggested a GUI interface which "lived on" a PBCC GRAPHIC WINDOW, see post #29. The idea has - let us say - been slow to catch on, but that is what I'm doing, anyway! The fact that in doing it I am turning away from the Windows GUI seems to have got up a few noses, but I shall bumble on, regardless.

[jcfuller]

Sorry Chris I didn't mean to ruffle any feathers. I only gave that Posting a light read originally and did not realize you had been fed a myriad of other possibilities while staunchly holding to your commitment. Carry On!

To me at this stage in my life (retired) the idea is to have fun and possibly provide some insight into the programming areas I researched over the last 30 years.



James

[Gert Voland]

>PBCC GUI's ???

James, sorry, I didn't find time to answer earlier.

Well, quite a few people (including me) seem to like the procedural way
of programming with PB/CC. My appreciation for the Graphic Window statements
has even increased since the keyboard and mouse events can be detected.

Sure, compared to the professional and stable SDK frameworks (such as PwrDev etc.)
these attempts still look like child's play ...

A side effect of writing something like the "Graphic Button" routines is that
you get familiar with (at least some of) the new features of PB/CC.
As a result there were discussions with PB support and feedback which hopefully
will be used to improve the product even more.

Maybe we'll see some real serious graphical applications programmed entirely
in PB/CC as soon as convenient routines for the user interaction exist
(such as buttons, file browser, text input, listboxes etc.).
And such an interface should have the emphasis on ease of use, modularity and
flexibility under full control of the programmer - isn't that the PB/CC style?
A feeling, BTW, that I often missed when I used the SDK frameworks.

Or is the question possibly, why has PB put the Graphic statements in PB/CC at all?
Well, my answer is clear - I like them a lot.

Best regards,
Gert Voland.

[Michael Mattias]

Maybe we'll see some real serious graphical applications programmed entirely
in PB/CC ..... buttons, file browser, text input, listboxes etc....

a. You can do that now with PB/CC. Nope, no intrinsic functions but very very doable.

b. You can do it now even easier with PB/Windows.

I would not hold my breath waiting for "CONTROL ADD LISTBOX" in PB/CC as long as that is part of the PB/Windows product.

[Gert Voland]

>You can do it now even easier with PB/Windows.

Michael,

No one doubts that. Don't have PB/WIN 9. And there are many more tools, too.

With the Graphic Buttons for PB/CC I managed to avoid subclassing and
still got the desired features working - of course with a few API calls.
And they work still in the procedural way. In their easiest form, QueryBox$,
just like WAITKEY$.

So, we'll just see how far we can take PB/CC to do some more in graphics.

Rgds,
Gert.