> <<Reply to
> Benjamin Scott
> 425.687.3955 >>
> <I welcome any other input. Please read Mr.s Scott's private e-mail reply
> at the end>
> No, Mr. Scott. My client is not Columbia Ultimate Business Systems -
though
> I do have a number of associates who work for CUBS.
> Do you have some experience automating Reflection from VB? I have done
> plenty of work with several ActiveX automation servers and have never seen
> the same type of behavior that I described in my request for CONSTRUCTIVE
> ASSISTANCE. I did compile my component as both an In-Proc DLL and an EXE.
> In both cases, Reflection doesn't yield control to any other process in
the
> chain while it is running - unique behavior indeed. Try this simple
> experiment - start a Reflection session from automation code behind a VB
> form in an executable project and give it something to do that will take a
> while (say, an hour or so.) During the session, try to set focus to that
> form. You can't! Interesting, isn't it? Again: all I want to do is
start
> up one (or more) automated Reflection sessions and then let my user
continue
> to use the application while they are running. I found a solution but it
> wasn't elegant.
> Did you have something constructive to add to this conversation? Your
> comment... "if an MCSD is unable to get an ActiveX server app going." is
not
> only rude but a display of sheer ignorance. Perhaps you missed the point
of
> my question in your zeal to criticize. I'm sorry, did you actually have
> some experience with this issue or were you just out and about passing out
> free advice? If you do actually know something about this, please
enlighten
> me. If not, then kindly educate yourself or {*filter*}out. It's possible that
I
> have missed something simple here but don't recall any questions
regarding
> the idiosyncrasies of terminal emulation software or mini/mainframe
systems
> on my MCSD exams - so no, I don't feel like an idiot after your childish
> remark. Seems the purpose of the public newsgroups community is to ASSIST
> developers with our eclectic experience in the industry (or you could just
> go around and find people to point and laugh at - that's your professional
> choice)
> So, Mr. Scott, why don't you step up to the plate and solve the problem?
> Show me two asynchronous background Reflection sessions launched from a VB
> app. that let's the user interact with a form while reflection is talking
to
> PICK.
> Paul Turley, MCSD, MCT, MSFCT
> www.createsolutions.net
> -----Original Message-----
> Sent: Friday, February 02, 2001 12:11 PM
> Subject: CUBS?
> I came across your post "Asyncronous method call and WRQ Reflection" in
the
> microsoft.public.vb.ole newsgroup and was wondering if the PICK system
> you're working with is Columbia Ultimate? Because, if an MCSD is unable to
> get an ActiveX server app going with Reflections, then I'll just give up
> now. Thanks,
> Benjamin Scott
> 425.687.3955
> --
> Paul Turley, MCT, MCSD, MSF-CT
> www.createsolutions.net
> Coauthor: Professional Access 2000 Programming, Wrox Press
> ** Please copy replies by e-mail **
> > I've solved this problem with a klugy work-around but I don't like the
way
> I
> > did it...
> > I need to multiple concurrent "batch" processes that pull results from a
> > mainframe database using automated WRQ Reflection sessions. I've
created
> a
> > COM component to do this that I intended to run from a remote server in
> MTS.
> > The problem is that even though my method call is asynchronous (i.e. the
> > method call finishes prior to a timer event which starts the actual
> > process,) The client code that fired the method gets stalled until the
> > entire process is finished.
> > Here are the ugly details:
> > I have a VB app that queues up batch jobs to extract data from a PICK
> system
> > using scripting in WRQ Reflection terminal emulation. Each of the
> requests
> > is saved as a record in an Access table that my app. reads in a loop,
> > deletes the current record (batch job request) from the queue table and
> > processes it. For each request, it fires up a Reflection session using
> OLE
> > Automation, sends a process request to the dark side and then when the
> > script finishes, saves the results into a text file on the PC. Since
each
> > of these jobs takes a while to run, I'd like to be able to run a
specified
> > number of them concurrently.
> > I have a class in a COM DLL component that does the automation against
> > Reflection. A method call uses a timer object in code instantiated from
a
> > timer control on a form in the project (there isn't any code behind the
> > form) - and then the method code completes. When the timer object
fires,
> it
> > starts the code that does the actual work. What I didn't expect is that
> as
> > soon as the automation code against Reflection starts a terminal
session,
> > the client code stops running until the Reflection session is closed.
> > Apparently Reflection knows how to hang the entire process while it
runs -
> > how selfish!
> > I ended up abandoning the whole remote component idea and created a
> > stand-alone EXE that I'm using to run instances at the same time - not a
> > cool server solution. Is there any way to spin off a new process after
> > killing the original object from the client? Any other ideas for
creating
> a
> > truly asynchronous process?
> > --
> > Paul Turley, MCT, MCSD
> > www.createsolutions.net
> > ** Please copy replies by e-mail **