search

openMSX / wxcatapult

23 stars 4 forks source link

[Bug] Type trough catapult / communication lost [sf#177] #9

Closed openMSX-import closed 9 years ago

openMSX-import commented 9 years ago

Reported by vampier on 2004-12-13 06:04 UTC When trying to paste a big text amount into openMSX trough catapult (input window) the communication between catapult and openMSX get lost. The only way to get it started again is to stop openMSX and restart.

Used text : http://www.gigamixonline.com/download/gigamix/msxfont _list1.php

openMSX-import commented 9 years ago

Updated by vampier on 2004-12-13 06:05 UTC

openMSX-import commented 9 years ago

Commented by manuelbi on 2005-09-21 21:14 UTC Logged In: YES user_id=78178

Hmm, when I try that listing, Catapult segfaults :(( I'm using a wx 2.6 build now, because 2.4 is a bit too old for my taste :P

openMSX-import commented 9 years ago

Updated by manuelbi on 2005-09-21 21:14 UTC

openMSX-import commented 9 years ago

Commented by m9710797 on 2005-12-17 13:31 UTC Logged In: YES user_id=356949

Problem was characters with bit 7 set. Such strings are possibly invalid UTF-8 strings.

I worked around this by dropping those chars.

openMSX-import commented 9 years ago

Updated by m9710797 on 2005-12-17 13:31 UTC

openMSX-import commented 9 years ago

Commented by joxy on 2013-07-30 03:28 UTC Needs a more thorough fix, as dropping chars is a workaround, not a solution.

openMSX-import commented 9 years ago

Updated by joxy on 2013-07-30 03:29 UTC

openMSX-import commented 9 years ago

Commented by m9710797 on 2013-07-30 08:25 UTC Since the time this bug report was created, the 'type' command in openMSX has been significantly improved. It now accepts UTF-8 input. If the MSX machine can type the corresponding characters, then it will just work. (Of course you still can't e.g. type Japanese characters on a non-Japanese MSX machine).

So fixing this bug could be as simple as just sending the data the openMSX. Properly converted to UTF-8, but that should anyway already be done.

openMSX-import commented 9 years ago

Updated by joxy on 2013-07-30 16:57 UTC

Diff:


--- old
+++ new
@@ -7,3 +7,13 @@
 http://www.gigamixonline.com/download/gigamix/msxfont
 \_list1.php

+(Patrick writes) so catapult 64bit keeps on crashing when text is
+being fed to catapult from openMSX
+
+we agreed in the past that we would use the 32bit instead
+
+(Wouterv writes) i don't remember, but i think we should instead
+fix it (now that wxcatapult code is active again)
+
+(Patrick writes) I think it was part of the wx framework
+
openMSX-import commented 9 years ago

Commented by manuelbi on 2013-07-30 17:53 UTC Is tehre any reason to think it's part of the wx framework? Has someone debugged this?

openMSX-import commented 9 years ago

Commented by vampier on 2013-07-30 20:53 UTC 2 different bugs entirely should not be put on the same ticket

On Tue, Jul 30, 2013 at 10:53 AM, Manuel Bilderbeek manuelbi@users.sf.net wrote:

Is tehre any reason to think it's part of the wx framework? Has someone debugged this?

[bugs:#177] Type trough catapult / communication lost + crashes of 64bit wxCatapult

Status: open Labels: wxCatapult Created: Mon Dec 13, 2004 06:04 AM UTC by Patrick van Arkel Last Updated: Tue Jul 30, 2013 04:57 PM UTC Owner: joxy

When trying to paste a big text amount into openMSX trough catapult (input window) the communication between catapult and openMSX get lost. The only way to get it started again is to stop openMSX and restart.

Used text : http://www.gigamixonline.com/download/gigamix/msxfont _list1.php

(Patrick writes) so catapult 64bit keeps on crashing when text is being fed to catapult from openMSX

we agreed in the past that we would use the 32bit instead

(Wouterv writes) i don't remember, but i think we should instead fix it (now that wxcatapult code is active again)

(Patrick writes) I think it was part of the wx framework

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/openmsx/bugs/177/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

openMSX-import commented 9 years ago

Commented by joxy on 2013-08-16 07:33 UTC

1. I've reviewed the code. The code for type button 
seems very small, clean and fine.

I cannot test this code as I only have CBIOS 
machines in my hardware listing at wxCatapult.

2. Maybe a 64-bit issues need to be tested and 
fixed if applicable, so I leave this ticket open.
openMSX-import commented 9 years ago

Commented by joxy on 2013-08-16 07:38 UTC The code for type button seems to not remove any chars, except for changing some control characters at tcl escape codes handling.

openMSX-import commented 9 years ago

Commented by manuelbi on 2013-08-16 17:46 UTC The crash is a different issue than the communication getting lost, right? Please refer to the ticket for the crash (I don't know which one that is exactly, but that one should be debugged with a debugger on Windows.) and use this ticket only for the communication getting lost.

openMSX-import commented 9 years ago

Commented by joxy on 2013-08-17 18:47 UTC Manuel, right.

I propose to split this ticket into two tickets: one (A) about comm. getting lost (closed), the other (B) about the crash (open).

Patrick, could you test (B) - does it crash at pressing of the Type button of wxCatapult? If it doesn't, we could close (B) as well, as "closed-works for me".

openMSX-import commented 9 years ago

Commented by vampier on 2013-08-18 00:42 UTC What I said is that text coming from openMSX to catapult crashes catapult on the 64bit version. This has to do with the way the text or fonts are handled. This is the 2nd time I say this and better remove my comment from this bug since it's not related :)

On Sat, Aug 17, 2013 at 11:47 AM, joxy joxy@users.sf.net wrote:

Manuel, right.

I propose to split this ticket into two tickets: one (A) about comm. getting lost (closed), the other (B) about the crash (open).

Patrick, could you test (B) - does it crash at pressing of the Type button of wxCatapult? If it doesn't, we could close (B) as well, as "closed-works

for me".

Status: open Labels: wxCatapult Created: Mon Dec 13, 2004 06:04 AM UTC by Patrick van Arkel Last Updated: Fri Aug 16, 2013 05:46 PM UTC Owner: joxy

When trying to paste a big text amount into openMSX trough catapult (input window) the communication between catapult and openMSX get lost. The only way to get it started again is to stop openMSX and restart.

Used text : http://www.gigamixonline.com/download/gigamix/msxfont _list1.php

(Patrick writes) so catapult 64bit keeps on crashing when text is being fed to catapult from openMSX

we agreed in the past that we would use the 32bit instead

(Wouterv writes) i don't remember, but i think we should instead fix it (now that wxcatapult code is active again)

(Patrick writes) I think it was part of the wx framework

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/openmsx/bugs/177/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

openMSX-import commented 9 years ago

Commented by joxy on 2013-08-18 01:20 UTC

Diff:


--- old
+++ new
@@ -6,14 +6,3 @@
 Used text : 
 http://www.gigamixonline.com/download/gigamix/msxfont
 \_list1.php
-
-(Patrick writes) so catapult 64bit keeps on crashing when text is
-being fed to catapult from openMSX
-
-we agreed in the past that we would use the 32bit instead
-
-(Wouterv writes) i don't remember, but i think we should instead
-fix it (now that wxcatapult code is active again)
-
-(Patrick writes) I think it was part of the wx framework
-
openMSX-import commented 9 years ago

Commented by joxy on 2013-08-18 01:27 UTC Patrick, done!

openMSX-import commented 9 years ago

Updated by joxy on 2013-08-18 01:28 UTC

openMSX-import commented 9 years ago

Updated by joxy on 2013-08-18 01:29 UTC