GUI front end for PICK
nobody@nowhere
There's an EXCELLENT package out from Unidata called wIntegrate. Search for
its description under the Unidata home page. It's a GUI builder that connects
Windows to PICK. Fantastic !
David Zigray
is that a personal recommendation?
WLMynorca
nobody@nowhere wrote:
>
> There's an EXCELLENT package out from Unidata called wIntegrate. Search
for
> its description under the Unidata home page. It's a GUI builder that
connects
> Windows to PICK. Fantastic !
And who exactly is nobody@nowhere?
Do you think they sell wIntegrate?
oliver st.john
nobody@nowhere wrote:
>There's an EXCELLENT package out from Unidata called wIntegrate. Search for
>its description under the Unidata home page. It's a GUI builder that connects
>Windows to PICK. Fantastic !
There's an EXCELLENT package out from Pixel called TERMiTE. No
searching required, just go to
www.pixel.co.uk
for a free, fully functional evaluation. It has a GUI front with
purpose built PICK subroutines. Fantastic!
And I'll sign my name...
Oliver St.John
And I'll tell you who I work for...
Technical Support Manager
Pixel Innovations Limited
oli...@pixel.co.uk
www.pixel.co.uk/tech_sup.html
Ed moxley
I'm partial to SB Client from Unidata/System Builder. It allows you to
build a great front end and then grow from there.
Try www.unidata.com for more info
Ed Moxley
Technical Project Leader for GUI Implementation
New Jersey
--
"I'll be late... I'm taking a short-cut."
Ed Moxley emo...@postoffice.ptd.net
jeff g.
Ed moxley (emo...@postoffice.ptd.net) wrote:
: oliver st.john wrote:
: >
: > nobody@nowhere wrote:
: >
: > >There's an EXCELLENT package out from Unidata called wIntegrate. Search for
: > >its description under the Unidata home page. It's a GUI builder that connects
: > >Windows to PICK. Fantastic !
: >
: > There's an EXCELLENT package out from Pixel called TERMiTE. No
: > searching required, just go to
: > www.pixel.co.uk
: > for a free, fully functional evaluation. It has a GUI front with
: > purpose built PICK subroutines. Fantastic!
: >
: > And I'll sign my name...
: >
: > Oliver St.John
: >
: > And I'll tell you who I work for...
: >
: > Technical Support Manager
: > Pixel Innovations Limited
: > oli...@pixel.co.uk
: > www.pixel.co.uk/tech_sup.html
: I'm partial to SB Client from Unidata/System Builder. It allows you to
: build a great front end and then grow from there.
I'm a bastard, so I'll put in my two cents. Termite and Wintegrate are
largely the same, they're both emulators which can dress up a char-based
app. I tend to lean toward Termite myself, for a variety of reasons,
although I suspect these two products will continually improve to overtake
each other, and which one is better will depend on what month you buy
them.
SB, on the other hand, is terribly proprietary, operates on a strange set
of standards, and will take you FAR off the path beaten by the rest of the
world. If you're worried about open systems and being able to hire people
off the street who can help you develop a GUI, SB may not be the best
choice.
jeff george
GeorgeLand
In article <50747i$s...@nntp.interaccess.com>, whizbang@interaccess (jeff
g.) writes:
>
>I'm a bastard, so I'll put in my two cents. Termite and Wintegrate are
>largely the same, they're both emulators which can dress up a char-based
>app. I tend to lean toward Termite myself, for a variety of reasons,
>although I suspect these two products will continually improve to
overtake
>each other, and which one is better will depend on what month you buy
>them.
>
>SB, on the other hand, is terribly proprietary, operates on a strange set
>of standards, and will take you FAR off the path beaten by the rest of
the
>world. If you're worried about open systems and being able to hire
people
>off the street who can help you develop a GUI, SB may not be the best
>choice.
>
>
What makes you think that Termite and Wintegrate are less proprietary than
SBClient? Or are you talking about SB+? Almost every piece of software,
Pick, Oracle, MS Access etc., is proprietary. They all have their own
ways of working and their own command sets, SB+ is no different. What
matters is open systems, the ability to talk to other products and, with
GUI, to present a common interface. Most of the issues are database
related and hence an SB+ application is in the same position as any Pick
based software. For the GUI SBClient is probably better than any other
tool available to the Pick developer. you can obtain a genuine GUI, not a
dressed up 80 x 24 screen. I did this for a 400 screen application some
months ago and it took less than a week, including developing DDE links to
other Windows products.
SBClient is a Microsoft approved Windows product and operates a strange
set of standards, they are the Windows standards. If you want to recruit
people off the street to develop your GUI then go ahead, by the time you
have got the interviews organised you could have got the job done.
George Land
APT Solutions Limited
GeorgeLand
>
>I'm a bastard, so I'll put in my two cents. Termite and Wintegrate are
>largely the same, they're both emulators which can dress up a char-based
>app. I tend to lean toward Termite myself, for a variety of reasons,
>although I suspect these two products will continually improve to
overtake
>each other, and which one is better will depend on what month you buy
>them.
>
>SB, on the other hand, is terribly proprietary, operates on a strange set
>of standards, and will take you FAR off the path beaten by the rest of
the
>world. If you're worried about open systems and being able to hire
people
>off the street who can help you develop a GUI, SB may not be the best
>choice.
Er, what? there's something standard about ESC [=Y1;X1;Y2;X2;LT;A1;...;An
z to draw a box using Termite? Are you talking about SBClient or SB+? SB+
is a 4GL - yes, it is proprietary in the same way as every other 4GL is
proprietary. SBClient is a separate product that takes SB+ applications
AND non-SB+ applications into a much more comprehensive GUI than either
Termite or Wintegrate.
One Monday morning some months ago I started with an application of around
400 character based screens, a copy of SBClient and no experience of
Windows programming. By Friday of the same week my application had a
complete GUI - not a jazzed up 80 by 24 screen but a true GUI. I was
exchanging data using DDE with Word and Excel. I was linking into WinFax.
I could run reports on my Pick data and choose the destination of my
output - screen, printer, Word, Excel in a pie chart format etc. In the
time it would take to interview people off the street to help develop your
GUI we have done it. We can now go on to enhance it, maybe add in some VB
and so on, but there is no hurry - what we achieved in a week has put our
application on a par in GUI terms with anything out there from any
background. Our application is SB+ based, had it been written in basic it
would have taken longer, but nothing like as long as it would take to do
it yourself.
SBClient is a Microsoft approved Windows product, it operates a strange
set of standards - they are the Windows standards. If you want to take
existing software into the centre of the path beaten by the rest of the
world then it is an excellent way of doing it.
Mark Preston
Ed moxley <emo...@postoffice.ptd.net> wrote:
>oliver st.john wrote:
>>
>> nobody@nowhere wrote:
>>
>> >There's an EXCELLENT package out from Unidata called wIntegrate. Search for
>> >its description under the Unidata home page. It's a GUI builder that connects
>> >Windows to PICK. Fantastic !
>>
>> There's an EXCELLENT package out from Pixel called TERMiTE. No
>> searching required, just go to
>> www.pixel.co.uk
>> for a free, fully functional evaluation. It has a GUI front with
>> purpose built PICK subroutines. Fantastic!
>>
>I'm partial to SB Client from Unidata/System Builder. It allows you to
>build a great front end and then grow from there.
Personally, I like Open Insight - now I've got used to it.
-------------------------------------------------
| Mark Preston Ma...@mpreston.demon.co.uk |
-------------------------------------------------
Ed moxley
400 screens in one week with SB+. I'm impressed. We took about 36 man
months to guitize 1500 screens that were not SB+ based, including
Windows based help, an automated installation process, a terrific
looking login and menu processor. Although it didn't hurt to have a 4GL
type of environment in place.
Back to being able to hire mainstream programmers.
Wintegrate and Termite definately have their places. Quick quitization
of a character product, that you will throw away after you write your
new one. So I see it 2 ways:
1. You could use Wintegrate or Termite to paint a pretty face on your
app and then rewrite your product using these simple :) steps:
1. Since some people are concerned with being able to hire able-bodied
programmers you should, fire all of your programmers
and hire new VB programmers right out of college. That's not as
cheap as it sounds.
2. Train these new people on your product. They then leave.
3. Take years (probably) to convert your product. Assuming, of
course your current product is worth keeping.
4. Spend countless dollars trying to get the project off the
ground. :(
5. Leave your current customer base out on a limb.
6. Realize it will never work and then do it the other way,
while your competition eats you for breakfast.
or you could:
1. Use a product such as SBClient to:
- evolve your product into the mainstream.
- start introducing object based ideas to your
development staff. It's easier to teach someone a language
then it is to teach them your product. It helps to be productive
as you are training.
- convert your screens into object based forms.
- do it as quickly as George has. Remember the market window!!
- spend less money.
- keep current customers happy.
2. Use what you learn in the process to move toward an open system,
whether it be Unidata or other environment.
I welcome any other methods.
Ed
Rich McLaughlin
In article <50747i$s...@nntp.interaccess.com>, whizbang@interaccess says...
>
>Ed moxley (emo...@postoffice.ptd.net) wrote:
>: oliver st.john wrote:
>: >
>: > nobody@nowhere wrote:
>: >
>: > >There's an EXCELLENT package out from Unidata called wIntegrate.
Search for
>: > >its description under the Unidata home page. It's a GUI builder
that connects
>: > >Windows to PICK. Fantastic !
>: >
>: > There's an EXCELLENT package out from Pixel called TERMiTE. No
>: > searching required, just go to
>: > www.pixel.co.uk
>: > for a free, fully functional evaluation. It has a GUI front with
>: > purpose built PICK subroutines. Fantastic!
>: > And I'll sign my name...
>: >
>: > Oliver St.John
>: >
>: > And I'll tell you who I work for...
>: >
>: > Technical Support Manager
>: > Pixel Innovations Limited
>: > oli...@pixel.co.uk
>: > www.pixel.co.uk/tech_sup.html
>
>: build a great front end and then grow from there.
>
>largely the same, they're both emulators which can dress up a char-based
>app. I tend to lean toward Termite myself, for a variety of reasons,
>although I suspect these two products will continually improve to
overtake
>each other, and which one is better will depend on what month you buy
>them.
>
>SB, on the other hand, is terribly proprietary, operates on a strange set
>of standards, and will take you FAR off the path beaten by the rest of
the
>world. If you're worried about open systems and being able to hire
people
>off the street who can help you develop a GUI, SB may not be the best
>choice.
>
>
> We were looking at the same at our place and chose VB with WinLink from
ViaSystems. From what I understand, Termite and Wintegrate let you
shrink wrap your app with windoes-like features, but your not doing any
real windows programming. Winlink will let you access Pick through ODBC
or APIs, which is nice. We have used the APIs and had front ends to some
of our Pick Screen done within a few days.
Doug Baldwin
Visual World-?? WIN version of PICK/Revelation GUI system-?
I got a slick brochure in the mail promoting Visual World. Supposedly
written by some of the people that brought Revelation out way back
when. The paradigm is based on the 'Visual Worlds' model.
There is a good developer deal to get started. Product is maybe
supposed to start shipping now. The beta download I tried seemed to be
a ways off from a finished product. I don't want to pay money to keep
beta testing this thing...
It is based on Pick and supposedly has conversion utilities for
Revelation conversion. Would others give it a look and tell me what
you think ?
Web site is at
Thanks !
Doug
jeff g.
GeorgeLand (georg...@aol.com) wrote:
: In article <50747i$s...@nntp.interaccess.com>, whizbang@interaccess (jeff
: g.) writes:
: >
: >I'm a bastard, so I'll put in my two cents. Termite and Wintegrate are
: >largely the same, they're both emulators which can dress up a char-based
: >app. I tend to lean toward Termite myself, for a variety of reasons,
: >although I suspect these two products will continually improve to
: overtake
: >each other, and which one is better will depend on what month you buy
: >them.
: >
: >SB, on the other hand, is terribly proprietary, operates on a strange set
: >of standards, and will take you FAR off the path beaten by the rest of
: the
: >world. If you're worried about open systems and being able to hire
: people
: >off the street who can help you develop a GUI, SB may not be the best
: >choice.
: >
: >
: What makes you think that Termite and Wintegrate are less proprietary than
: SBClient? Or are you talking about SB+? Almost every piece of software,
: Pick, Oracle, MS Access etc., is proprietary. They all have their own
: ways of working and their own command sets, SB+ is no different. What
: matters is open systems, the ability to talk to other products and, with
: GUI, to present a common interface. Most of the issues are database
: related and hence an SB+ application is in the same position as any Pick
: based software. For the GUI SBClient is probably better than any other
: tool available to the Pick developer. you can obtain a genuine GUI, not a
: dressed up 80 x 24 screen. I did this for a 400 screen application some
: months ago and it took less than a week, including developing DDE links to
: other Windows products.
: SBClient is a Microsoft approved Windows product and operates a strange
: set of standards, they are the Windows standards. If you want to recruit
: people off the street to develop your GUI then go ahead, by the time you
: have got the interviews organised you could have got the job done.
: George Land
: APT Solutions Limited
I would still operate on the idea that, if I am to GUI-ize a char-based
app, I can put a quick happy face on it with Termite or WIntegrate, then
acquire, quite easily and fairly economically, VB programmers, Delphi
people, FoxPro, whatever. To me, SB was something we had in the Pick
world when nothing else would connect. Now that Pick and the Uni-guys
have made themselves far more open, I would operate with something that
my larger prospects won't balk at in the event they want to switch to a
completely non-Pick database in the future.
With VB or Powerbuilder or whatever, they have those options in the
future. I'm not sure SB even has a future, given their current reorg at
Unidata. Ah, but that's another matter.
jeff george
Dave Meagher
> I'm not sure SB even has a future, given their current reorg at
>Unidata. Ah, but that's another matter.
>
>jeff george
Really jeff, what is it with you and SB? The constant inuendo that there 'is
something going on' with SB and Unidata appears to be a quite deliberate smear
campaign! If you have something to say about this, fears you wish to raise,
problems you want to air, then go right ahead! Just say what you mean, and
stop 'beating about the bush'.
Regards,
Dave Meagher (Was SB emp. now UniData Aust.)
GeorgeLand
In article <50k8k5$8...@nntp.interaccess.com>,
whiz...@thymaster.interaccess.com (jeff g.) writes:
>I would still operate on the idea that, if I am to GUI-ize a char-based
>app, I can put a quick happy face on it with Termite or WIntegrate, then
>acquire, quite easily and fairly economically, VB programmers, Delphi
>people, FoxPro, whatever. To me, SB was something we had in the Pick
>world when nothing else would connect. Now that Pick and the Uni-guys
>have made themselves far more open, I would operate with something that
>my larger prospects won't balk at in the event they want to switch to a
>completely non-Pick database in the future.
>
>With VB or Powerbuilder or whatever, they have those options in the
>future. I'm not sure SB even has a future, given their current reorg at
>Unidata. Ah, but that's another matter.
>
>
I am puzzled, I really don't know what you are talking about. Again are
we talking SB+ or SBClient?
SB+ is a tool to be used in developing applications. Your application
database will be Pick or Pick-like in the same way as if you wrote it in
basic. Now whatever you have written your application with, if it uses
Pick and your prospects want a non-Pick database in the future then they
are not going to buy your application. It doesn't matter what front-end
you put on it, your application is Pick based and, short of a complete
rewrite, is never going to be anything else. There are various possible
arguments here - are we talking about the merits of a Pick-based
application versus non-Pick, or are we talking about the best way to
develop a Pick based application or are we talking about the best way of
putting a GUI on a Pick application?
I maintain that if you are writing an application using a Pick-like
database then you have two realistic choices - you write it in basic or
you write it with SB+. If you want to put a GUI on that application then
you could put a 'quick happy face' on it with Termite or Wintegrate, you
could put a true GUI on it with SBClient or you could do something
yourself that in some way interfaces with your Pick application. I
maintain that SBClient is certainly the best way if your application is
written with SB+ and well worth looking at if written in basic. Doing
your own thing really doesn't achieve much except re-inventing the wheel,
unless you are taking the application out of Pick into another database -
that is yet another argument.
As for your suggestion that SB may not have a future 'given their current
reorg at Unidata' I suggest that this sort of comment is comletely
contemptible. You are implying that something is happening at Unidata in
a way that suggests that it is negative for the SB products without
substantiating that suggestion. In practice commercial logic says that
the SB products have a great future, there are so many companies who sell
applications software written with SB+ that it would be idiotic not to
continue with the product range. Our experience of Unidata since they
acquired System Builder is that they are putting considerable effort into
it and we have every reason to suppose that it has a great future. If you
have genuine reasons for suggesting that it has no future I suggest that
you state them clearly for everyone to judge.
Support
georg...@aol.com (GeorgeLand) wrote:
>
>As for your suggestion that SB may not have a future 'given their current
>reorg at Unidata' I suggest that this sort of comment is comletely
>contemptible. You are implying that something is happening at Unidata in
>a way that suggests that it is negative for the SB products without
>substantiating that suggestion. In practice commercial logic says that
>the SB products have a great future, there are so many companies who sell
>applications software written with SB+ that it would be idiotic not to
>continue with the product range. Our experience of Unidata since they
>acquired System Builder is that they are putting considerable effort into
>it and we have every reason to suppose that it has a great future. If you
>have genuine reasons for suggesting that it has no future I suggest that
>you state them clearly for everyone to judge.
>
>George Land
>APT Solutions Limited
I think it all depends upon whether you're a UniVerse user or a Unidata
user. As an SB+ user on uniVerse, I have noticed quite a change in
treatment since Unidata took over. Not only has there been less personal
contact (almost to the feeling of abandonment), but there is a push for
us to switch to Unidata, i.e. 'We'll help you with that if you
switch...'. Also, from what I've heard, the Unidata Users Conference was
deliberately planned to conflict with the UniVerse Users Symposium.
These things all make me wonder about the future of SB+ and UniVerse!
Terry Pennington
GeorgeLand wrote:
>
> In article <50k8k5$8...@nntp.interaccess.com>,
> whiz...@thymaster.interaccess.com (jeff g.) writes:
>
> If you want to put a GUI on that application then
> you could put a 'quick happy face' on it with Termite or Wintegrate, you
> could put a true GUI on it with SBClient or you could do something
> yourself that in some way interfaces with your Pick application.
[snip the rest]
I'm really confused about the comments appearing around these parts
regarding wIntegrate. It can be used in many ways, one of which is to
put a different face, I'm not sure about a pretty one, on a character
app by setting color attributes based on things like 'dim', 'reverse',
'blink' etc. This can give a colorful and chisled look to a standard 80
x 24 character screen, but's it's anything but GUI. It doesn't offer
in-place text editing, or other windows controls such as radio buttons
and check boxes.
But, wIntegrate can and does do that also. I've GUIized a complete
system with the product and once you figure out where the 'gotchas' are
it's a snap to do. Lots of code, but a snap nonetheless.
In fact, I'm no SB expert, but I believe wIntegrate will do much more
than SB because it works directly with windows and allows control over
printers, printer ports, screen functions, keyboard, on and on. I have
one workstation connected to an Intermec bar code printer on LPT1 and a
dot matrix on LPT2. Under the control of Pick basic, the station prints
bar code labels for shipping containers on one printer and, when
required, switches to LPT2 to print certificates required for certain
products. All the while a dialog box sits on the station's screen for
user interface with the process to enter work order numbers, quantities
and the like. The product seems to be limited only by a programmer's
imagination and the general limitations of windows.
Can't speak to Termite, however. Haven't used it.
Terry Pennington
Mukilteo WA USA
jeff g.
Dave Meagher (da...@sb.com.au) wrote:
: In article <50k8k5$8...@nntp.interaccess.com>, whiz...@interaccess.com wrote:
: >GeorgeLand (georg...@aol.com) wrote:
: >: In article <50747i$s...@nntp.interaccess.com>, whizbang@interaccess (jeff
[ everybody goes on and on]
: >
: >
: >I would still operate on the idea that, if I am to GUI-ize a char-based
: >app, I can put a quick happy face on it with Termite or WIntegrate, then
: >acquire, quite easily and fairly economically, VB programmers, Delphi
: >people, FoxPro, whatever. To me, SB was something we had in the Pick
: >world when nothing else would connect. Now that Pick and the Uni-guys
: >have made themselves far more open, I would operate with something that
: >my larger prospects won't balk at in the event they want to switch to a
: >completely non-Pick database in the future.
: >
: >With VB or Powerbuilder or whatever, they have those options in the
: >future
: Really jeff, what is it with you and SB? The constant inuendo that there 'is
: something going on' with SB and Unidata appears to be a quite deliberate smear
: campaign! If you have something to say about this, fears you wish to raise,
: problems you want to air, then go right ahead! Just say what you mean, and
: stop 'beating about the bush'.
: Regards,
: Dave Meagher (Was SB emp. now UniData Aust.)
Constant innuendo? Hardly. I made one mention. Don't forget, this is a
USERS' forum, not necessarily a VENDORS' forum.
I'll pop you a PRIVATE e-mail with my concerns, and if they are
unfounded, I will publicly apologize. How's that?
In the meantime, as someone who has built front ends with SB, VB, FoxPro,
Gupta, Powerbuilder, Termite, and Wintegrate, I still favor VB, with
whatever connectivity hooks happen to be handy. It's an opinion I'm
perfectly entitled to. Tell you what, this is my last contribution to the
thread, and then I'll move on.
jeff g.
Luke J. Bucklin
I know I'm probably posting this to the wrong part of this thread, but
I'm at the mercy of my newsreader.
I have been following this thread quite closely because I'm developing
a new Pick application and plan to start turning it into a GUI product
within the next few months.
Here are my thoughts, and I invite anyone to hand out their most
passionate opinions.
I think the Pick RDBMS has a lot of very good benifits. I've worked
with Dbase and Btrieve and have read about some other database
products. As far as I'm concerned, Pick is a really good database
product and I don't see much benefit to moving away from it. All I
need to figure out is how to develop windows-based software to
interact with the Pick database. I'm not even that worried about
maintaining the character-based application.
There are a lot of options being thrown out here: Wintegrate, Termite,
SBClient, etc. Also, for native implementations, there's PicLan's VB
interface. ODBC has been mentioned and now I've heard that it's a
good way to do it and that it's not a good way to do it.
I'm currently developing this app on R83, but it will be running on
AP/Pro. I've thought about putting a TCP/IP server on a system that
would communicate directly with the Pick server and develop the
application as a TCP/IP client application allowing a great deal of
flexibility. But the options are overwhelming and I'm sure each one
has it's place.
Here's my burning question. If you were going to develop a brand new
application from scratch, one that you wanted to be a marketable
application, would you think that a GUItized Pick application would be
a good idea? If so, what GUI front-end would you choose?
Luke J. Bucklin
------------------------------------------------------------
Luke J. Bucklin lbuc...@usinternet.com
Verity Data Corporation 612-350-7403
WLMynorca
jeff george writes
>With VB or Powerbuilder or whatever, they have those options in the
>Unidata. Ah, but that's another matter.
I would not bet on any client software that is not based on html (web
based). Anybody that wants to compete with the likes of Microsoft and
Netscape with everyone jumping on the bandwagon will likely go broke.
All my future development is based on a Web Browser client. I figure let
Microsoft work at getting the client to work correctly, they have the
money and time to invest in it.
Bill Lichtwald
Luke Webber
lbuc...@usinternet.com (Luke J. Bucklin) writes:
>Here's my burning question. If you were going to develop a brand new
>application from scratch, one that you wanted to be a marketable
>application, would you think that a GUItized Pick application would be
>a good idea? If so, what GUI front-end would you choose?
Since you asked the question; if marketability is the overriding factor,
go for an SQL database with a native Winblows front end. You can take
your pick what you use on the client end, but I can personally recommend
Delphi over VB. VB was fine until it had some competition, but I was
supremely happy to be able to drop it in favour of a *real* tool. Added
to that, VB just keeps getting fatter and fatter, in typical Microsoft
bloatware style, while Delphi comes from Borland, a company known for the
elegance of it's development tools. For a job such as this you'd want the
Client/Server version of Delphi.
As an alternative for the client side, you could look at some of the Java
tools coming out. They have the advantage of cross-platform support
(Winblows, Mac, Unix/X and probably OS/2 Merlin RSN, plus the Internet
and Intranets), but my feel is that they're still too young to be fully
featured, and Java is still too faddish for comfort.
I know I'm going to take some heat for recommending an SQL solution in
this group, but it *is* the correct answer. Sure SQL databases are
complicated and difficult and difficult to fine-tune, but the prospects
aren't going to want to deal with products they never heard of. You want
the market, you need magic words like Oracle, Microsoft, Sybase etc.
Remember that this is totally new development with no ties to Pick.
--
Luke Webber
* Note: The opinions expressed by Luke Webber are in no way supported *
* by his employers, Luke Webber Consulting Services *
jeff g.
Terry Pennington (ter...@accessone.com) wrote:: > whiz...@thymaster.interaccess.com (jeff g.) writes:
: >
Nothing I wrote matters, so I'll blast the rest.
: I'm really confused about the comments appearing around these parts
: regarding wIntegrate. It can be used in many ways, one of which is to
: put a different face, I'm not sure about a pretty one, on a character
: app by setting color attributes based on things like 'dim', 'reverse',
: 'blink' etc. This can give a colorful and chisled look to a standard 80
: x 24 character screen, but's it's anything but GUI. It doesn't offer
: in-place text editing, or other windows controls such as radio buttons
: and check boxes.
: But, wIntegrate can and does do that also. I've GUIized a complete
: system with the product and once you figure out where the 'gotchas' are
: it's a snap to do. Lots of code, but a snap nonetheless.
: In fact, I'm no SB expert, but I believe wIntegrate will do much more
: than SB because it works directly with windows and allows control over
: printers, printer ports, screen functions, keyboard, on and on. I have
snip, snip
SB is more OO, but is more of a chore. Whereas I can't see ultimately
deploying a client-server app wherein a char-based system calls up an
eumlator front end, it's a great way to get that windows look and feel in
a hurry, for marketability, while possibly developing the next generation
app using a Windows tool like VB or Delphi.
: Can't speak to Termite,however. Haven't used it.
Termite and Wintegrate are very, very similar. There are proponents of
each. They each have things the other lacks, each are easier to use in
different areas.
jeff george
Luke J. Bucklin
wlmy...@aol.com (WLMynorca) wrote:
>I would not bet on any client software that is not based on html (web
>based). Anybody that wants to compete with the likes of Microsoft and
>Netscape with everyone jumping on the bandwagon will likely go broke.
>All my future development is based on a Web Browser client. I figure let
>Microsoft work at getting the client to work correctly, they have the
>money and time to invest in it.
>Bill Lichtwald
I am having a difficult time accepting this as a solution for
GUItizing a Pick application based on current technology. I just can't
imagine using MSIE or Netscape as my front-end. I really don't think
HTML interfaces can compare with true Windows interfaces as far as
ease-of-use. The extensive flexibility of the web browsers seem to
add a level of complexity to a closed-in application that could cause
a developer (and a user) a great deal of frustration.
I agree with you to a certain degree. I believe the future is in the
internet and the user interface of the internet should some day be a
standard interface that everyone knows and loves. I just don't think
that time is close enough for us to jump on the bandwagon and start
developing business applications in HTML.
I would like to be enlightened with whatever it is that makes you
believe this is not a premature venture. I would love to believe that
HTML/Java have the functionality required to develop a competitive
application user-interface that actually works
.
Terry Pennington
Luke J. Bucklin wrote:
>
[snip]
> Here's my burning question. If you were going to develop a brand new
> application from scratch, one that you wanted to be a marketable
> application, would you think that a GUItized Pick application would be
> a good idea? If so, what GUI front-end would you choose?
>
> Luke J. Bucklin
>
> ------------------------------------------------------------
> Luke J. Bucklin lbuc...@usinternet.com
> Verity Data Corporation 612-350-7403
Luke,
I've appeared in this thread supporting the wIntegrate option. I still
think it's good but, starting from scratch, you should check out Pick's
new D3 and it's object-based VB tools. From what I can see, it's THE
way to go for new stuff....AND....if you've got time, the way to bring
legacy apps onto the toll bridge to the 21st century.
Terry Pennington
Mukilteo WA
jeff g.
Luke Webber (lu...@ozramp.ozramp.net.au) wrote:
: lbuc...@usinternet.com (Luke J. Bucklin) writes:
: >Here's my burning question. If you were going to develop a brand new
: >application from scratch, one that you wanted to be a marketable
: >application, would you think that a GUItized Pick application would be
: >a good idea? If so, what GUI front-end would you choose?
: Since you asked the question; if marketability is the overriding factor,
: go for an SQL database with a native Winblows front end. You can take
: your pick what you use on the client end, but I can personally recommend
: Delphi over VB. VB was fine until it had some competition, but I was
: supremely happy to be able to drop it in favour of a *real* tool. Added
: to that, VB just keeps getting fatter and fatter, in typical Microsoft
: bloatware style, while Delphi comes from Borland, a company known for the
: elegance of it's development tools. For a job such as this you'd want the
: Client/Server version of Delphi.
WAH! Then you weren't around in 1992 when Borland C went from 10MB to
45MB overnight. Running on my Gateway at the time with only 100MB total,
it was quite a squeeze.
In terms of speed, I would still take a multi-dimensional DBMS over a
strictly SQL DBMS anytime. I'm doing C++ types of objects now, but
granted, the stuff is *very* complex and not for everyone, and certainly
you won't put a database together nearly as fast as with a Pick-flavored
one. Administration on an SQL DBMS is also a big pain in the rear. My
experiences with Oracle have been great for my resume but lousy for my
digestion.
: As an alternative for the client side, you could look at some of the Java
: tools coming out. They have the advantage of cross-platform support
: (Winblows, Mac, Unix/X and probably OS/2 Merlin RSN, plus the Internet
: and Intranets), but my feel is that they're still too young to be fully
: featured, and Java is still too faddish for comfort.
I agree totally about Java, but Intranet front-ends are remarkably easy to
put together, and easy to maintain as well.
: I know I'm going to take some heat for recommending an SQL solution in
: this group, but it *is* the correct answer. Sure SQL databases are
: complicated and difficult and difficult to fine-tune, but the prospects
: aren't going to want to deal with products they never heard of. You want
: the market, you need magic words like Oracle, Microsoft, Sybase etc.
: Remember that this is totally new development with no ties to Pick.
It is up to the VARs to present the best solution, and to make the
prospect feel comfy with the fact that they're getting an open database.
Unidata and Universe are fairly open, I kind of wish Pick had been more
agreeable to Unix, maybe it will be to NT. But this is the VAR's job. I
DO know from experience that having a monster like Oracle on the back end
brings more costs to the table, despite Oracle's aggressive VAR pricing.
: -- : Luke Webber
: * Note: The opinions expressed by Luke Webber are in no way supported *
: * by his employers, Luke Webber Consulting Services *
jeff george
N.B. My opinions are in no way supported by my wife, because she doesn't
understand what the hell I do.
Mark Schramm
Why think in terms of GUIized "PICK" application? Why not just write a
Windows application that happens to have a PICK database. With ODBC (Which
is NOT slow), you can simply write your windows app in ANY windows
development environment and point it to PICK. You don't have to even
develop while pointing at PICK, you could point at ANY ODBC database and
then switch when you were ready (most people will prefer to connect
directly to PICK I think). The point is that to the Windows developer,
PICK looks like any other database except you keep the underlying speed of
the ACCESS Language. you can then hire any guy off the street with windows
development experience and away you go.
Cheers
Mark Schramm
Liberty Integration Software Inc.
Ma...@LibertyODBC.com
http://www.LibertyODBC.com
> Here's my burning question. If you were going to develop a brand new
> application from scratch, one that you wanted to be a marketable
> application, would you think that a GUItized Pick application would be
> a good idea? If so, what GUI front-end would you choose?
>
WLMynorca
Luke J. Bucklin writes:
>I would like to be enlightened with whatever it is that makes you
>believe this is not a premature venture. I would love to believe that
>HTML/Java have the functionality required to develop a competitive
>application user-interface that actually works
I may be a little prejudice as my company is just finishing an
object-oriented development environment that uses
HTML/Java/VBscript/ActiveX to deliver the client application inside a
standard browser.
While providing the functionality for applications involving heads down
data entry is probably 6 months away. The Internet is changing the way
companies currently do business, moving away from pools of data entry
clerks. They are moving the transaction closer to the source (i.e. the
person ordering the product does it over the Internet).
We have only shown the product to a couple of prospects and have already
signed one of the largest Australian Software houses (Pick based) as our
Australasia distributor.
The Internet solves so many of the inherent client/server problems it is
the only way to effectively produce enterprise wide applications. I will
let you know when our WEB site is up. I think you will be surprised at
the results being dynamically delivered by a Pick based system.
Bill Lichtwald
Bryan Buchanan
In article <50psj0$p...@newsbf02.news.aol.com>, wlmy...@aol.com says...
>
>Luke J. Bucklin writes:
>The Internet solves so many of the inherent client/server problems it is
>the only way to effectively produce enterprise wide applications. I will
>let you know when our WEB site is up. I think you will be surprised at
>the results being dynamically delivered by a Pick based system.
>
>Bill Lichtwald
I have some info on a Java(tm) interface to Pick. Look at
http://www.ats.com.au/~bryanb
We will have our on server on the Net soon, so you'll be able to
see real live Pick applications executing on the Web.
Bryan
Luke Webber
whizbang@interaccess (jeff g.) writes:
>Luke Webber (lu...@ozramp.ozramp.net.au) wrote:
>: lbuc...@usinternet.com (Luke J. Bucklin) writes:
>WAH! Then you weren't around in 1992 when Borland C went from 10MB to
>45MB overnight. Running on my Gateway at the time with only 100MB total,
>it was quite a squeeze.
[A little further off topic now]
Well yes, I was, but that wasn't a matter of the compiler bloating, it
was the cutover from C to C/C++ *and* the addition of Windoze support.
You can blame M$ for the Winblows side and Bjarne Soustrup <sp?> for the
rest. <g>
>In terms of speed, I would still take a multi-dimensional DBMS over a
>strictly SQL DBMS anytime. I'm doing C++ types of objects now, but
>granted, the stuff is *very* complex and not for everyone, and certainly
>you won't put a database together nearly as fast as with a Pick-flavored
>one. Administration on an SQL DBMS is also a big pain in the rear. My
>experiences with Oracle have been great for my resume but lousy for my
>digestion.
[snip]
>It is up to the VARs to present the best solution, and to make the
>prospect feel comfy with the fact that they're getting an open database.
>Unidata and Universe are fairly open, I kind of wish Pick had been more
>agreeable to Unix, maybe it will be to NT. But this is the VAR's job. I
>DO know from experience that having a monster like Oracle on the back end
>brings more costs to the table, despite Oracle's aggressive VAR pricing.
OTOH we in the Pick world tend to treat database adminstration as a
trivial matter, and we have some of the worst customers I ever heard of
(outside of plain DOS/Windows home users) for backup and validation. The
supposition that just anybody can run a database system with minimal cost
and virtually no care and feeding is frequently proven wrong, even in the
Pick world. At least the SQL databases make that clear.
>: * Note: The opinions expressed by Luke Webber are in no way supported *
>: * by his employers, Luke Webber Consulting Services *
>jeff george
>N.B. My opinions are in no way supported by my wife, because she doesn't
>understand what the hell I do.
Hell, neither does mine. Neither do I for that matter, but I don't let
that stop me. <g>
Luke
jeff g.
Mark Schramm (Ma...@LibertyODBC.com) wrote:
: Why think in terms of GUIized "PICK" application? Why not just write a
: Windows application that happens to have a PICK database. With ODBC (Which
THIS .... is the correct opinion. Pick a standard, common, open tool,
come up with a good app, then have a connectivity layer that doesn't tie
you to any one database.
jeff george
WLMynorca
Brian writes
>We will have our on server on the Net soon, so you'll be able to
>see real live Pick applications executing on the Web.
I have looked at this site and am impressed with what seems like a logical
extension to the Pick environment.
But! How does this help any developer generate and deploy applications
faster. You give them some nice tools BUT IT IS STILL TO HARD.
What I believe developers need is a good server side development
environment that reduces application complexity, reduces delivery and
maintenance cost, and just makes it easier. And of course it needs to
deliver application over Intranets and Internets using a public browser.
Take this utility and create an object-oriented development environment
and then you will have something many people can quickly use to extend the
life of their current application.
Bill Lichtwald
Joseba Real de Asua
Mark Schramm wrote:
>
> Why think in terms of GUIized "PICK" application? Why not just write a
> Windows application that happens to have a PICK database. With ODBC (Which
> development environment and point it to PICK. You don't have to even
> develop while pointing at PICK, you could point at ANY ODBC database and
> then switch when you were ready (most people will prefer to connect
> directly to PICK I think). The point is that to the Windows developer,
> the ACCESS Language. you can then hire any guy off the street with windows
> development experience and away you go.
I do not agree with this in one important question. What i love in Pick is that IT IS NOT LIKE
ANY OTHER DATABASE. It is multidimensional. if i want to constuct a system using ODBC i will work
with a relational model and i do not like the relational model. I prefer to use some APIs like
the Winlink one's and work in Visual Basic or Power Builder. Anybody that use this environments
will learn very quick how to read and write in a Pick Database. And i am still working with the
best database model I know. I will never use AP as a relational Database (well I may integrate
some Pick Data in other aplications with a relational model).
This is my idea, but you should do what you think is better
good luck
Luke J. Bucklin
>good luck
I really couldn't agree with you more. I have worked with other
databases and am very attracted to Pick as an RDBMS over other databse
models. For what I'm doing, ODBC may or may not be the right answer.
What do I have to gain by using ODBC for my new application? Pick is
easy to maintain, it's fast and it's not all that expensive. I could
use WinLink's ODBC interface but if I plan to stay with Pick this
creates additional overhead when compared to the API set.
I bought a new book on ODBC called "Inside ODBC" so I will be reading
that and learning what ODBC really has to offer, but it seems to me
that using a API like WinLink provides may produce the most efficient
and cost-effective client/server development environment for Pick.
LibertyODBC has a very comprehensive product from what I have
gathered, however, for small business applications, it drives the
costs up substantially.
I want to thank everyone who has provided their experienced insight
into this topic. CDP has proven itself to be an excellent forum for
discussing cutting edge development trends and it's refereshing to be
able to correspond with what appears to be the top 5% in Pick talent.
But let's keep this discussion rolling!
gordon till
Luke,
There is no way that I would develop a new product in any Pick
dialect. Especially a GUI one. If you have lots of code/data
structures in Pick that you want to migrate, go for it.
Otherwise, I would get a relational engine and a RAD tool (Delphi is
my choice, VB is useless, Powerbuilder is pretty good, and I'm going
to review the Oracle stuff soon.)
If you are developing a new product, do a market analysis first. What
benefit is the end user going to get by having a Pick based product?
What market are you going to be able to get into because you have a
Pick based product? If you've been programming for any amount of time,
you know the important part of being a programmer is being able to
provide solutions to the end user. So you have to learn a new
language...
Sorry about the soapbox, that's the way I see it.
Gordon
Joseba Real de Asua
> Gordon
Well Gordon:
I will never say to anybody what they MUST do. I only say what i would do. To write in this foro
saying that people should not use Pick is like if you are invited to a friend's house and when
you arrive there and he introduces you his wife you tell him in that moment and very loud, ohh
she is the ugliest women i have never seen.
You may think that you do not like Pick or you think it is not good. Then, why do you came to
this newsgroup?. I agree with you that what the end user needs are solutions. Pick HAS BEEN, IS
and WILL BE a good product for people to easily construct solutions to the end user. I agree too
in using a RAD tool but with a PICK engine. I prefer a multidimensional model better than a
relational model. it is easier and cheaper than the relational model. If you like ORACLE it is
OK. It is a good product. And Informix, SyBase, DB2, ingress, progress, etc..But I LIKE PICK.
What i think is that if you will never use, work, design etc. with Pick more you are losing your
time here.
Good luck (personally i think you will need it)
Francis
Phew.... !! I haven't visited the PICK group for a few weeks but what a
thread of items on this subject.
There have been some interesting and some controversial views on GUI front
ends for PICK. Since I have virtually been doing nothing else but client
front ends for PICK for the last 8 years with Pixel and TERMiTE, I feel I
am more than qualified to contribute to this thread.
Sometimes my views are themselves controversial but since I tend to speak
only from experience in this very field, the controversy is often in the
eye of the reader !!! (12 years ago at CMC, I wrote one of the first "GUI
front ends" for a PICK system using a bitmapped color terminal to display
moving graphical representations of disk I/O for Reality !!) - this was my
launch into 'rejuvenating legacy applications'…
Before I really start, I would like to comment that this subject applies to
all of the other legacy applications out there… My company has been
working, integrating TERMiTE with Progress, Informix, Dec Basic, Mumps and
many more host/legacy environments. Huge numbers of developers and users in
each these environments are voicing EXACTLY the same issues raised here, so
PICK developers, you are NOT alone !!!
To start with, one of the real issues comes when you look at Hype, who
would have believed 5 years ago that terminals would still be in use today.
Last year, according to statistics, more dumb terminals were sold than the
year before... Who would have believed that even a year ago ? Another
interesting fact is that one TERMiTE client (very large and NON-PICK),
shipped more than half of their terminal emulation licenses as DOS product
!!! - who would have believed that either… Still, things are on the move
again, eh ? What with Browsers, NT and and and… terminals are dead !! we'll
see…!!
The real issue of GUI comes when you look at **existing** legacy
applications, not new ones. And let's be frank, how many new applications
are being developed today in PICK ? Nothing like 10 years ago, right ? I
personally prefer to write in PICK, it's still fast, portable, flexible and
you can still write 1-5000 user supported apps in weeks and months, not
years !!
If developers take the plunge and rewrite their applications today using a
GUI only client solution, say VB or Delphi, how do they then support or
sell to existing users who still have bucket loads of dumb terminals. I
have seen large sites with dumb terminals turn away vendors for
applications that don't also run on dumb terminals. How do you distribute a
100 or 1000 user VB app over a Lan, Novell or Microsoft, how will it
perform, what back end database, who supports it when you now get a GPF and
not a GFE :-)
Let us also assume, that we don't really want 2 sets of our application
code, one written in say VB and the other written in PICK… How many of us
can afford this, support for 2 transaction based applications (with all the
locking, multi-user, networking, and data integrity issues this implies)
across 2 very different environments.
What a lot of people forget about PC only based applications is the
distribution of them. How many successfull 100,200, 500, 1000 user
transaction based windows applications have you seen installed. (Yes there
are examples but the point is 80% of legacy applications and dumb terminals
are still in use TODAY. Software companies have gone out of business
betting entirely on client server or Windows based apps as their only
offering).
So, let's for a moment assume that there is NOTHING wrong with our PICK
applications apart from the look and feel and the integration with the data
to other products on the desktop. If we all agree that this is the main
problem then we are half-way there to a solution J All we need to do, is
'beef' them up !!!
So, we ideally want to maintain one code set, so that if we decide say, to
add another field to a screen, we only have to change one set of code. With
non networked VB apps, don't forget you'd have to re-install the VB exec on
each PC again just because you added a field !!
This is where products like Via, TERMiTE, wIntegrate etc., come in.
Firstly, your PC users, get to access to your 'old' (but working) legacy
application running off the PICK server unchanged through one of these
terminal emulators. Dumb terminals also get the same access to the same
application of course.
Secondly, you can now initiate (under secure host control), file transfers
and data integration with Excel, Word (automate mailmerges), images, sound,
avi etc., straight through the intelligent TE's.
Thirdly, we now want to make the PC users have a better look and feel to
the current host application. For unstructured PICK programs this is much
harder… For instance to have a windows edit box for each field will require
lots of work. For structured applications, a couple of lines of code change
may be all that's required (for TERMiTE on screen GUI objects). We can now
GUI'ize our menus n hours using on screen objects since the concept of
GUI'ization through an intelligent TE is the same concept you would use to
add BOLD to your existing application. With a little bit of clever
programming (or using the free tools), a little event handler and you have
access to virtually every windows control, right alongside or on top of or
instead of your exisiting data. Sound easy, well it IS...
Of course, don't forget this solution is NOT an all or nothing like most
client or client/server solutions, you can provide as much or as little
integration and GUI as you like, you can release your software as you've
always done, your don't have to wait for major client CHUNKS OF CODE to be
completed before you go live…
Now we 'emulators' might not have the sexiest, flashiest GUI in the world
(watch this space for the new exciting developments too), but compared with
Green on Black and given the restrictions of working with EXISITING legacy
applications, there are very few choices for software houses. At the end of
the day, it works and seeing the joy on users faces having the PC
integration and look and feel they've waited years for is worth all the
effort. I continue fighting the case for keeping legacy applications alive
and fighting off the 'Fat Client' windows tools that never seem to quite
deliver…
Not only does this solution work, no only has it been delivered to 1000,'s
of users but it also applies to virtually every legacy environment, PICK
and non PICK...
too end...
I laugh when I look at a Web Browser today where suddenly, the server
software dictates everything the user does, not the client - sound
familiar. As the saying goes, "what goes around…"
My other comment of the day is, Fat clients are most definitely out. Let
the server do the work (they don't have much to do today anyway's :-) ),
let the client provide the user interface…….
My last question !! Is not a Web Broswer, just an intelligent terminal
emulator for text based HTML and plug ins…..
I hope I make sense. I know I've waffled but it summarises my feelings on
most of the contributions to this thread. Any questions, I'd be happy to
answer via email directly or via phone.
Francis
*********** P I X E L U S A Atlanta, GA. *************
Francis Carden
fran...@pixel.co.uk tel: (770) 512 7417
http://www.pixel.co.uk/ fax: (770) 512 7745
*************************************************************
********* F R E E E V A L U A T I O N S ***************
download from http://www.pixel.co.uk/
TERMiTE - future-proof terminal emulation and GUI integration
-------------------------------------------------------------
Luke J. Bucklin
Joseba Real de Asua <frel...@sarenet.es> wrote:
>> Gordon
>Well Gordon:
I do believe that there are many people on this newsgroup who are just
sick and tired of Pick but are, to their dismay, employed to work with
it. I am not one of them and I agree with Joseba on his argument that
Pick is a good system. I have worked with Dbase and Btrieve and it is
clear to me that Pick is a superior product over these simple database
systems. I haven't dealt with SyBase, ingres, Oracle, etc. However,
I do know that they are much more expensive than Pick is. If I can
provide a solution for and end user that is priced at $300/user for
the operating system that includes a GUI front end (developed in
Delphi, for instance), isn't that an example of keeping the end-user's
better interest in mind? What is it about Oracle or any relational
model that makes it so much superior to the multidimensional model
from an end-user perspective? I can develop ODBC compliant windows
software (if I wish to do so) using a powerful, inexpensive
multidimensional databse server that's easy to maintain.
I'm quite open to learning new languages and databases, as I am sure
the majority of the people on this newsgroup are. But, I would guess
that the majority of us are using Pick because ... We like it. We see
the value in the database model. Not because we're trapped in the
environment and lack the self-confidence required to get us into what
the others consider "the real world".
In any event, IMHO, I think there is more value in discussing to WHY
the relational models may provide a better development environment and
a more marketable product. Don't ask "What are the benefits of Pick"
or "What market are you going to get into using Pick". Give us a
foundation to discuss why Pick isn't a good choice and why a Pick
product is less marketable. I think we're all more open to a
discussion on that level.
Kevin Powick
>Mark Schramm wrote:
>>
>> Why think in terms of GUIized "PICK" application? Why not just write a
>> Windows application that happens to have a PICK database. With ODBC (Which
>> is NOT slow), you can simply write your windows app in ANY windows
>> development environment and point it to PICK.
The problem with developing your application in WindoZe and using ODBC
(which is slow) is that you cannot take great advantage of Pick basic.
Most updating would have to be done by passing massive amounts of data
from the Pick host to the client, updated on the client and then sent
back to the Pick host.
When having to succumb to the evils of client/server development for
WindoZe, I prefer to just pass a small amount of data to the Pick host
and have it run a Basic program to crunch the information and update
files.
I have found WinLink to be an excellent product for this. Although it
is now sold by Via Systems, I have been using it since it was first
written by Nick Pemberton of Amaron Software. It works very well and
integrates with any development environment that can call DLL's (C++,
VB, Delphi, Powerbuilder, etc).
Kevin Powick (k...@adan.kingston.net)
Trident Information Systems, Inc.
Kingston ON Canada
Joseba Real de Asua
Francis wrote:
>
> Phew.... !! I haven't visited the PICK group for a few weeks but what a
Thanks Francis. This is one of the best articles i have read in the newsgroup, the web,
magazines, etc. about GUI. It is clear that you have lived many years with the problem. Very
interesting for every any computer profesional or user. And very good for the Pick market in the
way that many times we think that we are the only ones with problems.
Thanks again
joseba real de asua
frel...@sarenet.es
RalphBres
All
Without getting dragged into the 'down and dirty' of the debate, I would
like to clarify the reorg statement. Unidata is a company whose products
are driven by their customers. This process is managed by product
marketing which is a department within marketing. It is interesting to
note that both the VP of Marketing as well as the Director of Product
marketing (responsible for all Unidata products) are respectively the ex
president of System Builder USA and The ex EVP of SB USA. I think this
speaks well to the future of the SB products within Unidata. Perhaps the
aquisition of a tools company by a DB company, based on synergy, which
results in sucessful joint product sales, is rather unique to our market
place, but don't let it scare you. SB is alive and well and moving rapidly
into the future. Watch for our solution to Web deployed GUI applications
which require only a WEB Browser to run. It is already available to select
customers and I believe will revolutionize developmet for legacy VARs (and
others too). For more info contact us off-line.
Regards
Ralph Breslauer
Unidata
Jim Idle
Kevin Powick <k...@adan.kingston.net> wrote in article
<51alvu$8...@gollum.kingston.net>...
> >Mark Schramm wrote:
> >>
> The problem with developing your application in WindoZe and using ODBC
> (which is slow) is that you cannot take great advantage of Pick basic.
I sort of agree. ODBC is MOSTLY slow.
jBASE OBjEX lets you get over some of this. It is entirely OLE based and
the easiest way to think of it is that it adds jBASE Basic to Visual BASIC
or anything else that will recognize OLE containers.
As it is OLE based you can implement things such as the three tier client
model. Or you just write a thin client or a thick client.
If anyone doubts where Microsoft are headed with ODBC, try looking up OLE
DB on their Website. Funnily enough this is not SQL based and is designed
for 'any' database not just a flat file model. It will support OLAP for
instance and something called a 'three-dimensional model' (wonder where
they got that idea eh?). In a reasonable timescale jBASE will support OLE
DB and you can forget all that stuff about having to normalize the data.
A bit harsh if you spent a lot of time making ODBC work, but I wonder how
many people have done here?
Jimi
William Sorensen
k...@adan.kingston.net (Kevin Powick) wrote:
>When having to succumb to the evils of client/server development for
>WindoZe, I prefer to just pass a small amount of data to the Pick host
>and have it run a Basic program to crunch the information and update
>files.
>I have found WinLink to be an excellent product for this. Although it
>is now sold by Via Systems, I have been using it since it was first
>written by Nick Pemberton of Amaron Software. It works very well and
>integrates with any development environment that can call DLL's (C++,
>VB, Delphi, Powerbuilder, etc).
I agree. Using WinLink to call a catalogged BASIC subroutine gives
amazing performance. It's more fun to write Delphi code than BASIC,
but life's a tradeoff.
++++
William Sorensen
te...@corenet.net
Mark Schramm
The Liberty Driver lets you call Catalogued BASIC subroutines from Windows.
Stinking fast!
--
Mark Schramm
Liberty Integration Software Inc.
William Sorensen <te...@corenet.net> wrote in article