Hi All,
The select statement isn't the problem, it's the restart. I'm pretty
certain that it's just due to the old window sending messages the select
does a peekmessage of NULL for the hwnd, this picks up all messages for that
thread.
The restarter wasn't closing the window so it's probable
The problem seemed to be based around the old window not getting destroyed,
windows still thinks it's there and sends forth more messages to it.
I've destroyed the window in the iohandler and the problem seems to be
solved. Sorry for the multiple posts just spotted it over a few days.
Chris
Hi All,
I think I've just identified a bug with select on /dev/windows. According
to the select code for the windows device it does a if (peekmessage()) then
in xwinclip it does the flushwindows upon select returning.
I've found a wierd circumstance were select returns but when the
Harold L Hunt II said:
I have searched for months and months for a way to receive a
definite signal that the X server is about to shutdown. There is a
hook provided by most window managers to indicate that the display
is closeing, but it has so far given mixed results. The last idea
I
I can't tell if you have enough of an understanding of X11 to write a
proposed solution that actually makes sense. At least, I can't make any
sense out of your proposal.
I understand what he's saying but XLib seems quite against the idea :
XSetIOErrorHandler is the first thing and the last
Harold,
As an aside this link explains that the only way is to longjmp/setjmp.
http://www.faqs.org/faqs/Xt-FAQ/section-19.html
If the intention is to fully integrate xwinclip into XWin then this would be
unwanted to say the least. Given XWin would close anyway you'd still want
xwinclip to
Chris,
Excellent detective work. It looks like longjmp setjmp is the way to go.
I will give it a try someday, unless you want to do it first.
The reason that catching a server reset is so important is that we
should not be killed when the server resets and we should try to connect
to the server
Chris,
Well, I am glad that someone is working on xwinclip other than me. However, I
did not respond to the proposed solution because I was not entirely convinced
that it was the best approach to take or even that a problem existed that
needed to be solved.
Of course, the best way to deal with
Hi All,
Thanks for the response Harold. I revised the logic in the changes and
managed to remove the threading and all that went with it. Guess what, the
XWin crashes stopped on both expected exists of xwinclip (via the stopping
tool I wrote) and via Ctrl-C/close command.
The problem I am
There is some obvious cleaning to do here. First, is to use only tabs or
only spaces (don't remember which one Harold uses). Having a mix of space
and tabs is a big mess for people who don't use the same tab size (8 vs 4
vs 3 vs 2).
I'll figure which one's are used and change the stuff
Jehan,
As far as integrating xwinclip into XWin.exe - Chris would be stuck by
the same problem that I am: that the process hosting the xwinclip X
client connection gets killed when X shuts down or resets and the client
connection is still open.
I have searched for months and months for a way
Jehan wrote:
Chris Twiner wrote:
Just of out interest did you try the changed version? I'm quite
interested to know if it works properly on other machines.
No I haven't. I rarely use XFree actually. I use it only when I have to
update some packages on our Linux servers.
But if I
Hi All,
I posted last week that I had a possible solution to the xwinclip selection
behaviour. I didn't get any feedback so I endeavoured to do it anyway. So
this ones a bit long but it's an explanation of how I've got it working ..
Basic premise :
Use a seperate dll that runs a system
I think the goal in the not-too-far-away-future is to have xwinclip
integrated directly inside the XWin app. This would save you the trouble
to use SetWindowsHookEx, which IIRC is a big piece of crap. Also, this
would save you the trouble of killing xwinclip while XWin is still running.
Hi All,
I'm a first time poster so appologies if I've misunderstood the etiquette
rules or not found a previous answer to this.
The message at :
http://sources.redhat.com/ml/cygwin-xfree/2002-01/msg00213.html
Lists polling as an unsatisfactory way of handling the ownership setting
issue.
15 matches
Mail list logo
