Re: [perl-win32-gui-users] Aborting a buffered write
Harald said:
| 1) instead of close, move the file pointer to eof
| seek FILE, 0, 2;
| so that the read fails without dying
This can't be, because the reading is from a socket not a file. I'm reading
from a socket
and writting to a file (in blocks of 10240 bytes). The read does stop when I
abort. This
method would certainly be good if I was reading from one file and ouptting to
another.
| or 2) just set a flag in the abort routine and if the reading routine finds
| the flag set, it peacefully quits.
The abort routine is not my method, furthermore it does not take any arguments,
it just
closes the socket and thus all data transfering.
The problem I believe is because since my application is GUI and event
driven(OOP), any
action one place jumps you to another section of code, without knowing how to
get back and
say, "hey stop doing that, move on". Does this make sense?
erick
never stop questioning
www.jeb.ca
| Hi Erick,
|
| 1) instead of close, move the file pointer to eof
| seek FILE, 0, 2;
| so that the read fails without dying
|
| or 2) just set a flag in the abort routine and if the reading routine finds
| the flag set, it peacefully quits.
|
| Hope that helps
| Harald
|
| -Original Message-
| From: Erick J. Bourgeois
| To: perl-win32-gui-users@lists.sourceforge.net
| Sent: 03.04.01 17:04
| Subject: [perl-win32-gui-users] Aborting a buffered write
|
| I have a process running, which is writting to a file(using print
| instead of syswrite),
| and I have a small dialogbox with a progressbar and an abort button. The
| problem is when I
| click the abort button, I get a GUI message "select: Bad file descriptor
| at ... line 412".
| This is the line where I read the data in, however, the event for the
| Abort button closes
| the data stream and the file I'm writting to. Plus the title for the
| window error is a
| subroutine which was a far ancestor to where it says the error is. This
| is what the
| Abort_Click looks like.
|
| sub Abort_Click {
| close(FILE);
| $data->abort();
| $ProgWin->Hide(); # <--progress dialogbox window
| $MainWin->SetForegroundWindow();
| $MainWin->BringWindowToTop();
| GUI::Update($MainWin);
| }
|
| I need a way tell the subroutine that is showing the progress to stop
| reading data and
| move on. Any ideas?
|
| erick
| never stop questioning
| www.jeb.ca
|
|
| ___
| Perl-Win32-GUI-Users mailing list
| Perl-Win32-GUI-Users@lists.sourceforge.net
| http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
|
RE: [perl-win32-gui-users] Aborting a buffered write
| The problem I believe is because since my application is GUI | and event driven(OOP), any | action one place jumps you to another section of code, | without knowing how to get back and | say, "hey stop doing that, move on". Does this make sense? I guess you're right, it is about multitasking. Reading from the socket places an asynchronous request somewhere. As data comes in, it gets stored in an input buffer. If the Abort routine intervenes and invalidates $data, the next read finds an invalid pointer or, worse, a pointer to an invalid buffer. If this theory is correct, then there is really no other way than to move the $data->abort() in the thread that reads from the socket, so that these two commands can never execute concurrently. If anyone knows more about the internal operations of the sockets driver, please stop me from making these wild assumptions ... :-) Have fun Harald
[perl-win32-gui-users] NonBlocking the Win32 Listen?
Ok. I have no clue what I'm talking about. I created AmphetaDesk: http://www.disobey.com/amphetadesk/ Roughly, it includes a built in webserver that listens until "quittin' time" for requests on port . It writes out logging information to STDOUT, which makes a pretty console window. Ok. What I want to do is make a GUI application using Win32::GUI. Since I know crap about coding a GUI (only about designing one), I handed this off to a friend, who has done VB stuff in the past, but nothing with Perl GUI's. The problem we're running into is something concerning the Window Events. My friend tells me that the Window needs to listen all the time so that it can know when to redraw the window, and blah blah blah. Lemme recap. The program starts a webserver. The program does some junk, and spits to console window. The program loads the browser. 90% of the GUI is done through the browser. While the user fiddles, the program spits info to the console window. The user quits. Ultimately, every where it says "console window", I'd like to replace with a GUI. But we run into the problem of the webserver listening for requests constantly, as well as the window listening to events constantly. I was able to tell the webserver to non-block, in other words, to listen for a request for 1 second and move on. What I'd like to have happen is that when the webserver moves on, the GUI window listens for events for a second, and then moves on as well. So, there'd be a 1 second time share between the webserver listening and the GUI window listening. Is this possible? And how? I'd like to: a) not fork b) be an all perl solution (ignoring the XS lib.) I've got a Mac GUI working in my dev machine, but am running pathetically short on the Windows GUI. Help?! Morbus Iff .sig on other machine. http://www.disobey.com/ http://www.gamegrene.com/
RE: [perl-win32-gui-users] NonBlocking the Win32 Listen?
| -Original Message- | From: Morbus Iff [mailto:[EMAIL PROTECTED] | | Ok. I have no clue what I'm talking about. Welcome to the club ;-) | to a friend, who has done VB stuff in the past, but nothing | with Perl GUI's. Takes some getting used to. Goes for both VB and Win32-GUI. Transitioning from one to the other can bring you close to serious brain damage because you forget to consider the different philosophies. Pretty much like changing from a car to a motorbike. You'll be amazed how fast and easy it is, but you wonder how to get your groceries home. | I was able to tell the webserver to non-block, in other | words, to listen | for a request for 1 second and move on. What I'd like to have | happen is | that when the webserver moves on, the GUI window listens for | events for a | second, and then moves on as well. So, there'd be a 1 second | time share | between the webserver listening and the GUI window listening. | | Is this possible? And how? Yes. I suggest you (and/or your friend) first go through the tutorial and Erick's wonderful collection of basic info @ http://www.jeb.ca/howto/The_Win32-GUI_HOWTO.html Once you know how (and how easy) to design a GUI, just do so. After Show()ing the window, when you usually give it full control using Win32::GUI::Dialog(), you just start your console program. And whenever this thing can spare a time slice (after the 1-second-listen), you do $abort = Win32::GUI::DoEvents(); which will make your GUI do what it wants to do, firing all pending events / messages. This call returns asap, ie when no more messages are in the queue. Now all that's left is exit your program if $abort < 0, and maybe one or two more interactions with the GUI, like evaluating user preferences from checkboxes and writing to textfields instead of printing to the console. And, again: FORGET WHAT YOU KNOW ABOUT VB. Doesn't help here. Basic knowledge about windows, controls, messages, methods, etc is OK, but that's it. Have fun Harald
Re: [perl-win32-gui-users] Aborting (now) an unbuffered write
Harald,
| If the Abort routine intervenes and invalidates $data,
| the next read finds an invalid pointer or, worse, a pointer to an invalid
| buffer.
That's the key thing. How to stop the routine from reading data once and for
all. Even
when I close the connection between the two handles it continues to read.
| If this theory is correct, then there is really no other way than to
| move the $data->abort() in the thread that reads from the socket, so that
| these two commands can never execute concurrently.
Maybe you are a bit confused. There are two abort routines. One fired by the
button being
pressed and the other to close the socket. Here is the loop that reads and
writes the data
from the socket.
# Open a socket for retrieval #
$data = $sock->retr($RemoteFile);
while(1) {
Win32::GUI::DoEvents();
last unless $len = $data->read($buffer,$blksize);
my $written = syswrite(FILE, $buffer, $len);
unless(defined($written) && $written == $len) {
Msg_Box("Cannot write to local file $LocalFile: $!",48,"Can't Write To
File");
$data->abort;
close(FILE);
return undef;
}
}
Then I have a window which displays the progress with an "Abort" button, which
I already
gave the code.
I need to exit this loop once and for all, once the connection has been closed.
The answer
is there...just gotta find it...someone...anyone.
regards,
erick
never stop questioning
www.jeb.ca
[perl-win32-gui-users] RE: Aborting (now) an unbuffered write
Yahoo, I figured it out!!! I did indeed need the global variable $abort, but another problem crept in. Long and the short of it is that when you abort a transfer, the socket gets closed at the same time, and after my loop I had a $sock->close(). My application froze here (I will investigate further why, I have an idea though), but I just needed to add $sock->close() if (!$abort); This actually helps tremendously, because, now you can have 5 queued transfers and abort one without affecting any others, that's great!! I can feel the brain coming back to normal... :) Thanks Herald, erick never stop questioning www.jeb.ca
