Re: Ada callable from Visual Basic?

Re: Ada callable from Visual Basic?

[Steve Doiel]

[snip]
>
>Oops, sorry.  Let me step down from my stump, and meekly ask my
>original question again:  How do I call Ada code from a Visual Basic
>GUI?
>
I'm not sure exactly how to do it with Visual Basic, but it's a trivial 
exercise to do it with Delphi and ObjectAda 7.1.  Presumably it's just as
easy to do with Visual Basic.

Using ObjectAda you can create a DLL that is callable from Delphi.  In 
ObjectAda you first create a package spec that contains everything to be 
exported by the DLL (for each DLL), and then in Delphi you create stubs that 
reference the DLL as external.

I believe you can do the same with GNAT.  As a matter of fact Pascal Obry has 
an example on his web page of how to call a GNAT DLL.  I haven't tried this 
with GNAT yet, but it took about 15 minutes to figure out how to make the 
Delphi/ObjectAda combination work the first time.

If you like, I'd be happy to email you my trivial example.

Steve Doiel
steved@pacifier.com

Ada callable from Visual Basic?

[Dave Smith]

Fundamental question first, in case you don't want to read the whole
post:

    Assuming well organized Ada software, with "business" objects
    separated from "view" (GUI) objects, is it feasible/cost-effective
    to replace a Motif GUI w/ a Win32 one using a mainstream RAD
    tool such as Visual Basic?

======

My question is loaded, so I'll try to give a little background:

I'm a scared developer.  I have seven years Ada experience.  As I
read Sunday's paper, I find week after week that everyone wants
Microsoft developers (yes, we're talking defense contractors here),
and I'm scared to death that I'll have to move to C++/Java for the
simple reason that no one does Ada anymore.  BTW, I'm *not*
scared to learn new things - I already know C++, and I prefer Ada.

I'm not in a financial situation that I can stick with Ada b/c it's a
superior
language (I have to feed my family).  However, I do not want to throw
the proverbial baby out w/ the bath water.  My real problem is NOT Ada
vs. C++.  Instead, it's the fact that I'm coding Motif/Xt by hand on an
expensive SG platform (whose processing power I don't need) while
my C++ buddies can use a sophisticated $300 tool (Visual Basic) to
build their GUIs in 1/10 the time on a cheap PC platform.

I know there are Ada bindings to Win32, but bindings a RAD tool do
not make (although bindings are still useful, since Win32 is not *only*
a GUI layer).  I know there are compiler vendors (Aonix) out there that
include Win32 GUI builders in their tools (prices not advertised,
multi-level price offerings, uh-oh!!!), BUT WHY??  Visual Basic is a
perfectly good GUI builder, and it will always have direct access to
the latest Win32 controls.  Ada vendors need to get out of the
mainstream GUI business.  To be fair,  Ada DOES need the ability to
build custom ActiveX controls in order to compete with Visual C++.

Ada compiler vendors need to ADVERTISE the fact that GUI
development is best left to a Visual Basic or Delphi, and concentrate
their marketing & development dollars on exposing C++'s
weaknesses.

To look at the problem from a different perspective, how sure am
I that Aonix's GUI builder will be alive 12 months from now? Not
very.  Visual Basic's?  Pretty sure.

Okay - how sure am I that 12 months from now, Ada is still going to
be a better language than C++?  Pretty sure.

Oops, sorry.  Let me step down from my stump, and meekly ask my
original question again:  How do I call Ada code from a Visual Basic
GUI?

Thanks,
Dave Smith

Re: Ada callable from Visual Basic?

[Larry Kilgallen]

In article <62calr$hsk$1@tsunami.traveller.com>, "Dave Smith" <dksmith@traveller.com> writes:

> I know there are Ada bindings to Win32, but bindings a RAD tool do
> not make (although bindings are still useful, since Win32 is not *only*
> a GUI layer).  I know there are compiler vendors (Aonix) out there that
> include Win32 GUI builders in their tools (prices not advertised,

I agree that covert pricing is bad, but the pricing itself is not
that bad.

> multi-level price offerings, uh-oh!!!), BUT WHY??  Visual Basic is a
> perfectly good GUI builder, and it will always have direct access to
> the latest Win32 controls.  Ada vendors need to get out of the
> mainstream GUI business.  To be fair,  Ada DOES need the ability to
> build custom ActiveX controls in order to compete with Visual C++.

So for you ActiveX is important, but for me it is not.  The reverse
could be true for GUI building.

> Ada compiler vendors need to ADVERTISE the fact that GUI
> development is best left to a Visual Basic or Delphi, and concentrate
> their marketing & development dollars on exposing C++'s
> weaknesses.

A requirement to mix tools is a very bad message to advertise.
Strong fans of any language want the ability to build a complete
application in that language That is different from saying that
they will always choose to do it that way.  The choice should be
one made due to the nature of the problem rather than tools availablity.
> 
> To look at the problem from a different perspective, how sure am
> I that Aonix's GUI builder will be alive 12 months from now? Not
> very.  Visual Basic's?  Pretty sure.

And what assurance do you have that the Visual Basic you get in 12
months will be the "same" as the Visual Basic you have today. Just
which standards bodies make Microsoft toe the line on compatibility.
This week press reports make it seem that not even a legal contract
with Sun will make Microsoft stick to a language definition.

Larry Kilgallen

Re: Ada callable from Visual Basic?

[James S. Rogers]

Al Christians <achrist@easystreet.com> wrote in article
<344B03EE.1A93@easystreet.com>...
> 
> Maybe the disposable software vendors have established a position that
> puts non-disposable software producers at a serious disadvantage in the
> mainstream.  You don't give your customer much extra value by
> engineering your product to go 30 years between failures if his OS fails
> every 30 minutes.   You don't give your customer much extra value by
> engineering your product to be maintainable for 30 years, when your
> competitors will make your products look obsolete every 30 months.

It is precisely this attitude which has contributed so well to the current
year 2000 problem.  I have seen estimates that the year 2000 problem will
cost $15,000,000,000 in US Dollars to correct.  This does not even begin
to cover all the costs associated with failed businesses, lost profits, and
lawsuits from customers and stockholders which await companies failing to
correct the problem in a timely manner.

The problems associated with the year 2000 problem have been known
about for more than 20 years.  The problem was perpetuated by the 
attitude that the software would never be in use long enough to be a
problem,
or that the software would be completely rebuilt at some later date, 
thereby
fixing the problem.  The software is being rebuilt now.  The cost is
staggering
due to the size of the problem and the procrastination in addressing the
problem.

Disposable software continues to appear attractive to business because
costs are still viewed only in the short term.  In the long term disposable
software reveals itself to be a symptom of a serious lapse in professional
ethics, costing many times more than it ever saves.

Jim Rogers
Colorado Springs, Colorado

Re: Ada callable from Visual Basic?

[Stephen Leake]

Steve Doiel wrote:
> 
> [snip]
> >
> >Oops, sorry.  Let me step down from my stump, and meekly ask my
> >original question again:  How do I call Ada code from a Visual Basic
> >GUI?
> >
> I'm not sure exactly how to do it with Visual Basic, but it's a trivial
> exercise to do it with Delphi and ObjectAda 7.1.  Presumably it's just as
> easy to do with Visual Basic.

I tried writing a DLL with ObjectAda and then calling it from Visual
Basic. VB complained it couldn't find the function. I believe the reason
is that the DLL that OA made did not have the function names in its
headers. In Windows 95, you can use Quick View (right mouse in Explorer)
to look at the header of a DLL and see what it exports; the function VB
was trying to find did not appear. In other DLLs that VB can use, the
functions do appear. Apparently, for the DLLs from ObjectAda, the
function names are only in the import lib, which is what Delphi, C, and
C++ look at. 

Apparently there is more than one way to build a DLL! Does anyone have a
definitive reference? The MS help files are not enough.

I have not looked at DLLs from GNAT.

(Thank you Microsoft, for such a well defined and consistently followed
standard) (I can see it now; ISO standard DLLs from Ada95!).

-- 
- Stephe

Re: Ada callable from Visual Basic?

[Al Christians]

Larry Kilgallen wrote:

>> And what assurance do you have that the Visual Basic you get in 12
months will be the "same" as the Visual Basic you have today. Just
which standards bodies make Microsoft toe the line on compatibility.
This week press reports make it seem that not even a legal contract
with Sun will make Microsoft stick to a language definition.  <<


I have seen a growing consensus amongst developers targeting MS Windows
that the long life cycle is hopeless in that environment.  They admit
that the RAD tools seduce even good developers into creating lamentably
unmaintainable programs.  Yet, they are resigned to a 'why fight it?'
attitude, knowing that they can find work next year to replace the
results of this year's rush projects.  When nothing that your program
has to talk to is expected to last more than three years 
(the OS, the hardware, the network, the database, etc), what good does
it do to try to build anything to last longer?  What difference does it
make if when your program gets rewritten along with everything else,
that it's going to be rewritten in the same or a different version of
the same or a different language?

Maybe the disposable software vendors have established a position that
puts non-disposable software producers at a serious disadvantage in the
mainstream.  You don't give your customer much extra value by
engineering your product to go 30 years between failures if his OS fails
every 30 minutes.   You don't give your customer much extra value by
engineering your product to be maintainable for 30 years, when your
competitors will make your products look obsolete every 30 months.

Al

Re: Ada callable from Visual Basic?

[Tom Moran]

> You don't give your customer much extra value by
>engineering your product to be maintainable for 30 years, when your
>competitors will make your products look obsolete every 30 months.
  Sounds like a call for reusable software components - the car will
be obsolete soon, but the same nuts and bolts and tires and tubes will
be used in the next cars. 

Re: Ada callable from Visual Basic?

[Jerry van Dijk]

In article <62calr$hsk$1@tsunami.traveller.com> dksmith@traveller.com writes:

>To look at the problem from a different perspective, how sure am
>I that Aonix's GUI builder will be alive 12 months from now? Not
>very.

As this GUI builder was already present in the Ada83 compiler...

> Visual Basic's?  Pretty sure.

Yes, but will the next version still work with your current code ?

>Oops, sorry.  Let me step down from my stump, and meekly ask my
>original question again:  How do I call Ada code from a Visual Basic
>GUI?

The easiest way (and a very good one at that) is to compile the Ada
code into a DLL.

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Ada callable from Visual Basic?

[Dave Smith]

>...Presumably it's just as easy to do with Visual Basic.
>
>Using ObjectAda you can create a DLL that is callable from Delphi.  In
>ObjectAda you first create a package spec that contains everything to be
>exported by the DLL (for each DLL), and then in Delphi you create stubs
that
>reference the DLL as external.


Sounds great.  Now for my second question (I'm about to display my Win32
ignorance here):  Is it possible to go in the other direction (Ada -> VB or
Delphi)?  I do this now (w/ my GNAT to Motif/Xt code) in order to set up
callbacks.

Cheers,
Dave

Re: Ada callable from Visual Basic?

[Dave Wood]

Larry Kilgallen wrote:
> 
> In article <62calr$hsk$1@tsunami.traveller.com>, "Dave Smith" <dksmith@traveller.com> writes:
> 
> > I know there are Ada bindings to Win32, but bindings a RAD tool do
> > not make (although bindings are still useful, since Win32 is not *only*
> > a GUI layer).  I know there are compiler vendors (Aonix) out there that
> > include Win32 GUI builders in their tools (prices not advertised,
> 
> I agree that covert pricing is bad, but the pricing itself is not
> that bad.

You'll find this quite common with international companies.
The web does not know national boundaries.  With exchange 
rates, shipping charges, and/ or distributor overhead, 
prices can vary a bit from country to country, and fluctuate
over time.  Providing a full price matrix is both confusing 
to customers and high maintenance for the supplier.  A 
simple phone call or email to the local office will 
provide the desired answer.  In the US, 1-800-97-AONIX.

Even in a single country, there are a lot of different
prices for ObjectAda packages.  They start at $0 (!!) 
and cover a broad range depending on a lot of factors
(platform, feature set, type of user, etc.)

> 
> > multi-level price offerings, uh-oh!!!), BUT WHY??  Visual Basic is a
> > perfectly good GUI builder, and it will always have direct access to
> > the latest Win32 controls.  Ada vendors need to get out of the
> > mainstream GUI business.  To be fair,  Ada DOES need the ability to
> > build custom ActiveX controls in order to compete with Visual C++.
> 
> So for you ActiveX is important, but for me it is not.  The reverse
> could be true for GUI building.

But I find this interesting, because if you want to, you can
build your ActiveX control in C++ and import it into the
GUI Builder (v7.1.1), which would seem to be exactly what you
are asking for.  Reusable components written in other languages.

> 
> > Ada compiler vendors need to ADVERTISE the fact that GUI
> > development is best left to a Visual Basic or Delphi, and concentrate
> > their marketing & development dollars on exposing C++'s
> > weaknesses.
> 
> A requirement to mix tools is a very bad message to advertise.
> Strong fans of any language want the ability to build a complete
> application in that language That is different from saying that
> they will always choose to do it that way.  The choice should be
> one made due to the nature of the problem rather than tools availablity.

I say use whatever combination of tools suit the problem.  For
some people, the ObjectAda GUI Builder is all they want or need.
For others, they will want to work with Delphi.  Some others
will want to work only at the MFC level.  Or gbObjects (the
object library included with the GUI Builder).  Or CLAW.  The 
point is all of these are appropriate in different situations
and all can and will work together.

> >
> > To look at the problem from a different perspective, how sure am
> > I that Aonix's GUI builder will be alive 12 months from now? Not
> > very.  Visual Basic's?  Pretty sure.
> 
> And what assurance do you have that the Visual Basic you get in 12
> months will be the "same" as the Visual Basic you have today. Just
> which standards bodies make Microsoft toe the line on compatibility.
> This week press reports make it seem that not even a legal contract
> with Sun will make Microsoft stick to a language definition.
> 

There aren't a lot of guarantees in life, even with Microsoft.
Have you ever heard of Bob?  For that matter, DOS or Windows 3.1?
MS Mail?  MS Exchange (dying a fast death)?  WinHelp?

On the other hand, the GUI Builder has been around, in one form
or another, for several years.  Aonix has been around, under one
name or another, for 15 years...

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "We don' need no steenking mandate!"
-- http://www.aonix.com