>> It's possible, but painful.
More painful than about 10 years of manual rewrites? I just want to get
everything working in .Net while I go back through and fix things. If I can
write something to handle the UI, then I can move everything over and start
working on reworking the most important stuff first. If the other stuff
runs slow, is not scalable, a little sluggish in performace, then that's ok.
That is much better than rewriting it all from scratch and having to wait 10
years for any of it.
>> But what about the loop that controls how the page is built? No
disrespect, but the loop looks a
>> little odd. Do you really want multiple headers and footers? Surely
not. It doesn't look like
>> you're controlling how *a* page is built; it looks like you're
>> generating
a series of pages, each
>> one >>>determined by the "return value" from the previous page. In
>> which
case, why not just use
>> postback?
Your right, that is what I am doing. It is odd for .Net or for any
event-based lanugage. However, it is the way FORTRAN, GB_BASIC, COBOL, etc.
all work... assuming that I really recall enough about these lanuages. In
these languages you build the screen programmatically using some screen
definiation syntax. You then place the logic in a loop so the screen will
run until the user hits a key indicating that the program should exit.
Typically in these lanuages you will create a common header and footer but
create a unique page content for each page. Then the loop will use the
header and footer and simply replace the content within. I can get that to
work fine. What I cannot get to work is to get IE to return and continue
within the loop. The loop is destoryed because the postback doesn't
maintain the state of the loop. Can you think of a way to maintain the
state of the loop after the postback and then return to within the loop?
>> Yep. That really does sound like postback. You'd handle the
>> stateful
aspects via session state, not by trying to do it all within one ASPX.
>> Apologies if I'm missing something here (and I probably am *sigh*).
It sort of is, but the problem is that in a non event-driven language, the
code builds the UI and the UI is not a separate set of code like an ASPX
page and it's code behind. It just all Basic or COBOL or whatever langague
you are using. They don't separate the UI. Also the program can
communicate with the UI anywhere within code. So they can have dozens of
loops like my sample and have then throughout the app and even in other
subroutines and other called apps. My idea of create some sort of function
to hand off the UI to the user and have it return was to try to handle the
uniqueness of the non event driven logic.
Here is another version of my sample. This may give you a better idea of
what's going on.
Dim strSomethingFromTheUI as string = ""
Dim strStatus as string = "userControlMainPage"
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
If Not Page.IsPostback Then
ExecuteUILoop()
Else
'? Take me back to the functions and loops but somehow set
the loop back up.
' i.e. if I was in ExecutePage2(), go back! If I was in
ExecuteUILoop, take
' me back there but set the loop back up. If I go there
without setting the
' loop back up, I just fall through and exit the loop. I
want the loop to
' continue working.
End If
End Sub
Private Function ExecuteUILoop()
Do Until strStatus = "STOP"
LoadControl("Header")
LoadControl(strStatus)
LoadControl("Footer")
strSomethingFromTheUI = HandeOffToIE()
Select Case strSomethingFromTheUI
Case "Exit"
strStatus = "STOP"
Case "Next"
strStatus = "userControl2"
ExecutePage2()
Case "Prev"
strStatus = "userControl3"
ExecutePage3()
End Select
Loop
End Function
Private Function ExecutePage2()
'Do page two stuff here
strSomethingFromTheUI = HandeOffToIE() End Function
Private Function ExecutePage3)
'Do page three stuff here
strSomethingFromTheUI = HandeOffToIE() End Function
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ivan Towlson
Sent: Monday, July 04, 2005 2:37 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Using a Thread to pipe commands to IE
> Is it possible to write something like HandOffToIE()?
It's possible, but painful. Between somehow getting IE to listen on the
appropriate port (and respond appropriately) and the ever-popular sport of
persuading the NAT and firewall to cooperate, not to mention dancing around
Back buttons, timeouts, etc. etc. etc., a method that tries to drill from
server to client is asking for trouble.
What may be more promising, and what I suspect those "others" do, is to
drill instead from client to server. Let your ASPX page run to completion
without waiting for the client to do its thing. Then, in some client-side
JavaScript, open a connection back to the server, and have IE send
information over that connection.
But what about the loop that controls how the page is built? No disrespect,
but the loop looks a little odd. Do you really want multiple headers and
footers? Surely not. It doesn't look like you're controlling how *a* page
is built; it looks like you're generating a series of pages, each one
determined by the "return value" from the previous page. In which case, why
not just use postback?
> The old UI is able to execute code, then it pass the UI to the user,
> then the user interacts with the screen, and then the control returns
> the code and continues.
Yep. That really does sound like postback. You'd handle the stateful
aspects via session state, not by trying to do it all within one ASPX.
Apologies if I'm missing something here (and I probably am *sigh*).
--
manaaki whenua | manaaki tangata | haere whakamua
http://hestia.typepad.com/flatlander | mailto:[EMAIL PROTECTED]
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
