From: "Steve Doiel" <nospam_steved94@attbi.com>
Subject: Re: object ada, visual c and tasking combined.
Date: Sat, 16 Feb 2002 04:14:53 GMT
Date: 2002-02-16T04:14:53+00:00 [thread overview]
Message-ID: <11lb8.68374$Pz4.332450@rwcrnsc53> (raw)
In-Reply-To: 3C6CC24D.D013A4AC@chariot.net.au
"john donoghue" <donoghue@chariot.net.au> wrote in message
news:3C6CC24D.D013A4AC@chariot.net.au...
> Hi all,
>
> I have a problem that perhaps someoneelse has encountered before and
> found a way around.
> Firstly, I have some legacy ada code that amongst other things displays
> some stuff on a display via a custom graphics controller board.
> Recently it has been decided to upgrade that by replacing the existing
> graphics code with a visual c front end.
Yuk. I always hate to see C replacing Ada in any context, oh well.
> All well and good, I can build a gui in visual c in several cpp files
> and link it in after defining a few pragmas to access the c
> functionality - first problem with objectAda ...
> it complains about conflicts between libcd.lib having variables that are
> alreadt defined.
> And also it complains about linking in some of the visual c dll's etc
> and unresolved symbols and more.
In the "pass to linker" options of ObjectAda try /nodefaultlib. I've seen
something similar, but not quite the same that this corrected.
> After getting sick of that, I decided to try compiling the gui part in
> to a dll and link that to the ada code ... hey it works ... but to be
> compatible with the old graphics stuff, the dll has to also call a few
> ada functions that are within the main ada application ... no problem
> ... let's send a structure from the ada code to the visual c code on
> initialization that contains pointers to the functions that the c code
> will need to call later.
> ... It seems to work ... next problem .... The visual c windowing stuff
> is in its own task, and there is also another C task that needs to wait
> on an ada function to return with data - but everytime I call the
> "pointered" functions from these tasks the app spits the dummy (
> terminates with a exception that provides no name or message or
> anything. )
I had a similar problem. In my case I registered a callback with the DLL
that needed to wait for something in on the Ada side. When I tried having
the callback wait on a protected type, I don't remember the specific
behavior, but bad things happened.
The way I got around this is using the Win32 API objects, although I can't
remember specifically which object, and I don't have the code handy. The
Ada code creates the win32 (I'll call it a semaphore) and sets its state to
empty. The callback trys to take the semaphore and pends until the
semaphore is given.
I hope this helps,
SteveD
> I am guessing that you cant call the ada functions from the other C
> tasks since they are in other tasks to the ada functions :) ... but is
> there a way around it?
>
> Cheers,
> John
>
next prev parent reply other threads:[~2002-02-16 4:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-15 8:09 object ada, visual c and tasking combined john donoghue
2002-02-15 18:06 ` Stephen Leake
2002-02-15 18:34 ` tmoran
2002-02-15 20:29 ` john donoghue
2002-02-16 4:14 ` Steve Doiel [this message]
2002-02-23 13:36 ` Nick Roberts
2002-02-25 12:05 ` john donoghue
2002-02-25 13:20 ` Frank J. Lhota
2002-02-25 20:10 ` Randy Brukardt
2002-02-27 20:53 ` john donoghue
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox