Thanks for the suggestion, but they are normal command buttons. And it
looks like everything is normal, I have an hourglass, etc. but it's not. I
can click option buttons or delete values from text boxes while the server
is being called. I appreciate knowking that it works for you, however, I
now just have to figure out where things went wrong for me.
"Frank
Feldmann" To: <[EMAIL PROTECTED]>
<frank@silver cc:
stream.be> Subject: RE: repost: Re-entrancy
problems using java
server and vb client
12-07-01
12:43 AM
Please
respond to
soap-user
I have the following working:
SilverStream app server with Apache soap.
Registered java classes wrap around the SilverStream xCommerce
product and make it soap aware. One of their enablers (producers)
XML enables a mainframe. I use this to have an Excel spreadsheet
retrieve the mainframe data by sending a soap request to the SilverStream
server -> into xCommmerce -> into mainframe and then return the output
to the calling client app in a soap response.
The Excel thing uses the 2.0 SP2 toolkit from MS with VBA code.
I have buttons as well, but they remain pressed while the SOAP
communication
is taking place. Check the button type you have used, sounds more like
there
is a different button on your form then a normal command button.
Good luck,
Frank Feldmann
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 12, 2001 1:46 AM
To: [EMAIL PROTECTED]
Subject: repost: Re-entrancy problems using java server and vb client
Apologies for the repost, but I am having a difficult time figuring this
one out, and I hope that someone can offer a bit of advice. Perhaps the
previous questions were too detailed...
If possible, is there anyone out there who has a java server that is being
accessed by a VB client using the MS soap sdk? If so, what is the expected
behaviour with respect to client processing? The problem that I have is
that a command button that does some action can be clicked repetedly before
the response from the server comes back. Is it just me, or is that how it
always works? If so, is it the MS sdk, or something else?
I could put a hack in the event -- some boolean flag that says Processing,
and exit the routine if it's true, but I hate doing stuff like that, it's
so cheezy.
Thanks again..
<Old post>
I have a relatively simple soap server that I've written in Java. It takes
the call, hits a database, and returns a result -- it takes a couple of
seconds to execute. The client is written in VB, and it calls the server
with a command click event.
I've noticed that as soon as the soap call takes place, I can click the
command button again and again even though the first call hasn't come back.
This is very odd for vb, which is thread retarded, so I'm a bit confused.
I'm not sure where my problem lies. I don't know if the problem is a
result of the ms soap transport, the vb code that I've written, or the way
the soap/tomcat server works. Note, I have not used doEvents in my code,
the re-entrancy issue (I'm quite sure, anyway) is a result of soap.
</Old post>
--
NOTICE: The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential. If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
corrected.
Frank Feldmann
Manager eBusiness Strategy
SilverStream Software EMEA
Mobile : +31 622429856
e-mail: [EMAIL PROTECTED]
--
NOTICE: The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential. If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
corrected.
