PB\Win Help Files 
Author Message
 PB\Win Help Files

I am contemplating purchasing powerbasic for Windows and would like to look
at the help files that would be included with the purchase of same.  I did
not find a place that I could download the help file on their website.

I would appreciate guidance.

Thanks

Trento Castricone



Fri, 29 Apr 2005 00:16:15 GMT  
 PB\Win Help Files
I think that is on purpose.  It would be illegal, I think, for
any of us owners (I have PB/CC 2.11) to forward those copyright
materials to you.

Although making the help files available does seem to me a good
way to promote the products.  (hint!).


Quote:

>I am contemplating purchasing PowerBasic for Windows and would like to look
>at the help files that would be included with the purchase of same.  I did
>not find a place that I could download the help file on their website.

>I would appreciate guidance.

>Thanks

>Trento Castricone

--
cheers
Jonathan Berry
http://www.islandnet.com/~jberry/      to know more than you want


Fri, 29 Apr 2005 05:28:13 GMT  
 PB\Win Help Files
I searched the book stores for any thing on PowerBasic - nothing !!
I searched the internet for anything on PowerBasic - a fair amount of code
(some good, some bad.)
I am NOT interested in programming in DOS !!
I have been programming professionally in Visual Basic since version 1.
I just purchased and am learning Visual Studio.Net.
I hope that PowerBasic will give me advantages.  ( Real Dll's they say!)

With the PowerBasic Help File I should be able ascertain the following.
     How hard and what hoops you have to jump through to use the many
ActiveX's(Ocx) I have?
     What if any Internet capabilities does PB\Win have?
     How extensive is the ability to use existing Windows API's?
     How hard is it to make a DLL that can be used by any windows
programming language?
     How capable is the PowerBasic IDE?
     Is the Power Basic Forms Designer really able to import Visual Basic
forms?

I have many more questions that could be answered in the PowerBasic Help
Files.

Thanks
Trento Castricone


Quote:
> I am contemplating purchasing PowerBasic for Windows and would like to
look
> at the help files that would be included with the purchase of same.  I did
> not find a place that I could download the help file on their website.

> I would appreciate guidance.

> Thanks

> Trento Castricone



Fri, 29 Apr 2005 21:02:07 GMT  
 PB\Win Help Files

Quote:

> With the PowerBasic Help File I should be able ascertain the following.
>      How hard and what hoops you have to jump through to use the many

ActiveX's(Ocx) I have?

No hoops, because you cannot use OCX's with 'native' PowerBASIC. (I believe
there is a third-party product which supports this). The latest compiler
versions support COM 'client' programs, but unless I am mistaken, OCX's
require the using program have COM server capabilities.

Quote:
>      What if any Internet capabilities does PB\Win have?

'native' verbs for TCP and UDT; and see next for HUGE expansion .....

Quote:
>      How extensive is the ability to use existing Windows API's?

Almost 100%. There are a small handful of restrictions, mostly related to
multi-thread code. Also, if you use the "DDT" syntax to create dialogs,
there are some additional rules/restrictions/changes to standard Windows
behavior on message processing.

Quote:
>      How hard is it to make a DLL that can be used by any windows

programming language?

Not hard at all. I do it all the time. Would you like to make a purchase?

Quote:
>      How capable is the PowerBasic IDE?

YMMV. It's a preference thing. You can edit, compile, run and get help on
verbs. There's also a stepping de{*filter*}, but I do not use it. (I make no
statements about the stepping de{*filter*}'s capabilities, I just do not use
it). Plus in the latest compilers there are some really nice debugging tools
such as TRACE and CALLSTK (call stack analysis).

Quote:
>      Is the Power Basic Forms Designer really able to import Visual Basic

forms?

Do not know, I don't use either VB or the forms designer. (Waste of money
for me, since I'm real comfy with both the 'canned' Microsoft Dialog Editor
and the CreateWindowEx API call).

Quote:
> I have many more questions that could be answered in the PowerBasic Help

Files.

Seems to me you got most answered here...BUT.. for for crying out loud, just
write or phone or email the PowerBASIC sales department. That's what sales
people do. Make them earn that paycheck!

MCM



Fri, 29 Apr 2005 22:28:39 GMT  
 PB\Win Help Files

Quote:

>No hoops, because you cannot use OCX's with 'native' PowerBASIC. (I believe
>there is a third-party product which supports this). The latest compiler
>versions support COM 'client' programs, but unless I am mistaken, OCX's
>require the using program have COM server capabilities.

No, the term "OCX" just a file extension like EXE, DLL, and does not
provide any insight into what it might contain (except that it is very
likely to be a COM component of some type... and there are a number of
different types!

PowerBASIC can be used to create COM Client applications because it
supports COM components that act as COM servers (both in and out of
process) and expose a dispatch interface and have a ProgID.  

PowerBASIC does not support COM Controls (variously known as ActiveX
Controls) because PowerBASIC does not (yet!) provide COM Container
functionality which is required to "host" a COM Control.

Quote:
>Also, if you use the "DDT" syntax to create dialogs,
>there are some additional rules/restrictions/changes to standard Windows
>behavior on message processing.

That is a bit vague.  ther are essentially two types of callbacks:
those for dialog windows, and those for SDK-style windows.  PowerBASIC
supports both types.  DDT callbacks comply very closely with how you
would do conventional dialog callback processing. For example, you
return non-zero if you handle a message in a DDT/Dialog callback,
whereas you'd return zero for a SDK-style callback.

Quote:
>>      Is the Power Basic Forms Designer really able to import Visual Basic
>forms?

>Do not know, I don't use either VB or the forms designer. (Waste of money
>for me, since I'm real comfy with both the 'canned' Microsoft Dialog Editor
>and the CreateWindowEx API call).

PB/Forms imports from VB form files and it generates an equivalent DDT
dialog and code template for it.   Since VB uses it's own
"superclassed" custom controls, PB/Forms substitutes standard controls
in the template.  

Basically, the dialogs produced by PB/Forms will appear visually as
close as possible to the original VB form.  PB/Forms does not import
any VB code that may reside in the form file.

Quote:
>> I have many more questions that could be answered in the PowerBasic Help
>Files.

>Seems to me you got most answered here...BUT.. for for crying out loud, just
>write or phone or email the PowerBASIC sales department. That's what sales
>people do. Make them earn that paycheck!

{smile}

PowerBASIC offers a 30-day money-back guarantee on all products
(except when shipped electronically), so yes, call our 800-line and
talk to our sales staff... they would love to talk with you about our
products!  (Operators are standing by!)  8-)

I hope this helps!

Lance
PowerBASIC Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Sat, 30 Apr 2005 01:24:57 GMT  
 PB\Win Help Files

Quote:

> >Also, if you use the "DDT" syntax to create dialogs,
> >there are some additional rules/restrictions/changes to standard Windows
> >behavior on message processing.

> That is a bit vague.  ther are essentially two types of callbacks:
> those for dialog windows, and those for SDK-style windows.  PowerBASIC
> supports both types.  DDT callbacks comply very closely with how you
> would do conventional dialog callback processing. For example, you
> return non-zero if you handle a message in a DDT/Dialog callback,
> whereas you'd return zero for a SDK-style callback.

That's what I mean. While I almost never use DDT, I know there was a) some
variation to start with and B) some kind of change in the rules with v 7.0
regarding assigning the return value of a window/dialog proc.. under "pure"
Windows ("SDK Style")  you SetWindowLong (hWnd, %DWL_MSGRESULT) return true
for a dialog, but return the actual value you want if not a dialog. Under
DDT (which are all dialogs) you set the function value to the value you want
returned or something like that.  Too hard for an old fart like to remember
two different things like that.

MCM



Sat, 30 Apr 2005 04:51:16 GMT  
 PB\Win Help Files


Quote:


<snip>
> ... The
> latest compiler versions support COM 'client' programs, but unless I
> am mistaken, OCX's require the using program have COM server
> capabilities.

The new compiler can load many OCX's.  Depends upon the supported
interface. OCX's are COM servers and the applications are COM clients.

PowerBasic application may NOT be COM servers.  Not yet anyway.  

Just can't wait to try out my new upgrades that arrived today. When I
saw examples of programs that instantiated ADO and connected to SQL
server I new that I had to have it.

I have a need to write data aware TCP/IP server applications that
support a lot of clients.  The built in threading will make my life
easier.

Don't forget builtin (native) serial communication.  I do lot's of
industrial applications.  Lots of factory floor and shop floor machinery
use serial IO and serial printers for industrial labeling are very much
an everyday kind of a thing for me.  There are several manufacturers of
devices that turn remote serial data into TCP/IP packets. The software
on the server turns this back into COMM ports.  Just think of opening
COMM 39 and printing a mailing label on a printer in another state.

--
ATB

Charles Kincaid



Mon, 02 May 2005 09:00:27 GMT  
 PB\Win Help Files

Quote:
>  The built in threading will make my life easier.

I'd be careful about saying 'built-in' multi-threading. Writing good
multi-threading code is not "point-and-shoot," especially if you need to
share some - but not all - data across threads.

If you've never written Windows programs before, a multi-threaded
application is probably best left for your SECOND project.

MCM



Tue, 03 May 2005 21:21:28 GMT  
 PB\Win Help Files


Quote:


>>  The built in threading will make my life easier.

> I'd be careful about saying 'built-in' multi-threading. Writing good
> multi-threading code is not "point-and-shoot," especially if you need
> to share some - but not all - data across threads.

> If you've never written Windows programs before, a multi-threaded
> application is probably best left for your SECOND project.

> MCM

True.  Just like TCP/IP and COMM programming are much easier in PB than
in VB they are not simple and free of complications.

But then since I have been programming for a living since September of
1972 I have lost COUNT of the number of projects. :)

--
ATB

Charles Kincaid



Tue, 10 May 2005 04:06:34 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. help file to PB/DLL32 5.0

2. PB Fortran DLL / Win NT4

3. pb with proble-file and dot file

4. File locking in Win 95/Win NT

5. Win-help file does'nt show contents

6. How to make Win Help files using Tcl

7. HELP! w/virus corrupting Win files

8. PB 3.2.PB/Vision 2.0 Timerinstallcode.Shared Arrays

9. MX Lookup with PB/CC or PB/DLL

10. TCPADDR for PB/DLL & PB/CC

11. Info on new PB/CC and PB/DLL

12. Announcing the JazzAge COM Wizard for PB/DLL and PB/CC

 

 
Powered by phpBB® Forum Software