openMSX / Bugs (DISABLED) / #177 Type trough catapult / communication lost

Patrick van Arkel - 2004-12-13

summary: Type trough catapult / communcation lost --> Type trough catapult / communication lost
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Manuel Bilderbeek - 2005-09-21

priority: 5 --> 7
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Manuel Bilderbeek - 2005-09-21

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Wouter Vermaelen - 2005-12-17

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Wouter Vermaelen - 2005-12-17

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2013-07-30

Needs a more thorough fix, as dropping chars is a workaround, not a solution.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2013-07-30

labels: Catapult --> wxCatapult

status: closed-fixed --> open

assigned_to: Herman Oudejans --> joxy

Group: --> Next_release

Priority: 7 --> 5
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Wouter Vermaelen - 2013-07-30

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

summary: Type trough catapult / communication lost --> Type trough catapult / communication lost + crashes of 64bit wxCatapult
Description has changed:

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
+

Manuel Bilderbeek - 2013-07-30

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Patrick van Arkel - 2013-07-30

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/

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2013-08-16

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.

Last edit: Anonymous 2013-08-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2013-08-16

The code for type button seems to not remove any chars, except for changing some control characters at tcl escape codes handling.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Manuel Bilderbeek - 2013-08-16

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2013-08-17

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".

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Patrick van Arkel - 2013-08-18

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".

[bugs:#177] http://sourceforge.net/p/openmsx/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: 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/

Related

Bugs (DISABLED): ~~#177~~
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Description has changed:

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
-

Anonymous - 2013-08-18

Patrick, done!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2013-08-18

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2013-08-18

summary: Type trough catapult / communication lost + crashes of 64bit wxCatapult --> Type trough catapult / communication lost
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Type trough catapult / communication lost

Group

Searches

Help

#177 Type trough catapult / communication lost

Related

Discussion

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

Related