eSWT: display.post() verschluckt "special characters" (alphanumerisch)

hallo ihr lieben,

ich hab ein problem mit der methode post(Event event) der klasse Display.java. sie ist dafür da, nativ über das betriebssystem tastatur-input zu simulieren. an sich ist das seitens eSWT nur für testing-zwecke gedacht, ich brauche es allerdings nicht nur dafür sondern produktiv,... (bitte keine diskussionen über die art der lösung; im moment geht es nur damit und leider nicht anders).

mein konkretes problem: wenn ich an die methode "normale" characters (a-z, A-Z) oder digits (0-9) übergebe, funktioniert alles tadellos, der tasten-druck wird genau so auf dem gerät simuliert, wie es sein soll. bin ich allerdigns außerhalb dieses bereichs, werden die zeichen einfach verschluckt; der führt auch teilweise offensichtlich falsche befehle aus, denn wenn ich zB "[" an die methode schicke, öffnet sich in der java-applikation plötzlich die windows-taskbar... hier wird also eindeutig etwas falsch interpretiert.

leider hab ich weder sourcen noch sonst was von der nativen methode, die dann innerhalb von display.post() verwendet wird (.dll), hab aber inzwischen seit über einer woche alle blackbox-tests gemacht, die man sich vorstellen kann (siehe unten). ich brauche diese funktionalität unbedingt, und ich bin mir sicher, dass hier nur eine kleinigkeit fehlt...

system:
- windows ce 5
- java 1.4.2 (IBM J9)
- eSWT (teil der eRCP)

alles, was ich bereits unternoemmen haben, steht in komprimieter form (ja, es war noch viel mehr... trail and error, nur error...) unten. google hab ich mehrere stunden dazu befragt; hätte mich sonst nie extra bei einem eclipse-forum angemeldet...

wenn jemand damit erfahrung hat, bitte hier damit rein, ich bin mit meinem latein ziemlich am ende. wäre für jede hilfe dankbar und würde das sehr, sehr dringend brauchen!

bitte lest euch auch den englischen thread durch, wo wesentlich mehr infos drinnen stehen. er ist vermutlich zu kompliziert, weswegen ich vl auch noch keine antwort im eclipse-forum erhalten hab, aber naja,... ich dachte, viel information is besser als wenig/keine...

-----------------------------------------------------------------------

Dear all,

I am new to business, as well as new to this forum here... so I want to apologize in case this article/thread is already present in a similar way. I looked for it over 10 minutes, but I couldn't find any threads which somehow match or treat my problem.

So as the title already says, the library, the operating system behind or something else kinda swallos my special characters.
(what special characters are for ME: no digits (values) and no characters from a to z and A to Z. perfect example: - (dash))

background information and working scenario: I need to use the display.post(Event event) method as I need to simulate key and button presses (scanner device). (to be sure, the class org.swt.eclipse.widgets.Display.java is the correct and the only one I am talking about here.) furthermore, display.post() automatically uses the currently focused input field where the keys are inserted then. so if a scan is performed with the barcode scanner, the characteres and digits are automatically inserted into the input field (except for the special ones).

testing system: Symbol WT4090 device with Windows CE 5 operating system.
application that uses all this stuff: JAVA 1.4 using eSWT (eswt-converged-1-1.jar; eswt-converged.dll).

What already works (with implementation below): If it is a digit or a character, everything works perfectly. the characters (even on demand the capital ones (SHIFT)) are posted into the input field. each of the characters outside this range - the special characteres from above - does not work at all.


what i already figured/tried out (and of course did not bring me to the desired result in any way):


- exchaning the eSWT-libs (which was not successfully; device did not even start the application)
- all masks and combinations from SWT-constants (especially the interesting keyCode ones and the constants mapped by OS.java also) which were a lot,...
- hard key events from SWT
- different encodings of barcodes => each of them end up in the same result
- took a look at the characters and keyCodes which apply to the ACSII table => should be correct as the digits and characters can be posted perfectly
- took a look at the encoding which was not UTF-8 by default by the JVM, but should be correct also because of the same reason


current JAVA 1.4 implementation which works with a-z, A-Z and digits (as already said):

Code:

/**
     * Posts a sequence of key events simulating a key stroke.
     * 
     * @param display display where the events should be fired
     * @param character character of the key to be pressed
     */
    public static void postKeyStroke(Display display, char character) {
        final boolean shift = Character.isUpperCase(character);

        character = Character.toLowerCase(character);
        if (shift) {
            postKeyEvent(display, SWT.KeyDown, SWT.SHIFT);
        }
        postKeyEvent(display, SWT.KeyDown, character);
        postKeyEvent(display, SWT.KeyUp, character);
        if (shift) {
            postKeyEvent(display, SWT.KeyUp, SWT.SHIFT);
        }
    }

    /**
     * Simulates a key event.
     * 
     * @param display display where the event should be fired
     * @param eventType type of the event
     * @param keyCode key code of the key to be "pressed"
     */
    public static void postKeyEvent(Display display, int eventType, int keyCode) {
        final Event event = new Event();

        event.type = eventType;
        event.keyCode = keyCode;
        display.post(event);
    }

so do you see any problems in this implementation? do i have to deal with the special characters in a completely different way? are there any restrictions to those special characteres in eSWT? I am quite sure that swt is able to deal with them, there MUST be another problem, a wrong usage of the library...

does anybody have experience with that method and the usage and is able to help me?
i am sitting here for more than a week, and it's quite urgent as it is not possible testing without the dashes.

in case something is not entirely clear, or there is a lack of information, please just ask me! I am quite desperate already and very thankful for any kind of help or clue getting closer to the solution!

thank you very much for reading and already in advance for help,
stefan

-----------------------------------------------------------------------

TIA,
sYbb

Zitat von that

Von dem eSWT sollte es doch auch irgendwo den Sourcecode geben, oder? Den würde ich mir mal besorgen und anschauen.

zwar versteckt, aber sie sind da:

http://www.eclipsezone.com/eclipse/forums/t114393.html

und ja, sourcen lesen bringt in dem fall sicher am meisten

Zitat von sYbb

Eswt macht alles richtig bis zum aufruf der nativen methode, eher die sourcen davon waeren hilfreich (dll), die den call dann schlussendlich ans OS weitergeben,...

Ja, von dem red ich ja. Hier:

http://dev.eclipse.org/viewcvs/inde...amp;view=markup

ok, ich bin inzwischen einen schritt weiter und hab es mit der neuen version (und am furchtbaren pfusch, ohne den es net gangen wär) geschafft, das ding teilweise zu starten. auch mit dem neuen source-stand von eSWT liegt das problem immernoch vor. der fehler muss also an der art meiner events liegen, die ich an die display.post() übergebe.

hat hier jemand erfahrung damit, welche maske ich setzen muss, damit das system den übergebenen wert auch wirklich als sonderzeichen erkennt? er interpretiert SICHER falsch, wenn wenn ich eine "[" scanne, poppt die taskleiste auf, wie schon gesagt,...

per shortcut ist's möglich, ja (so wie die meisten keys auf dem device). es geht gar net um die taste konkret, ich wollte damit nur unterstreichen, dass er sehr wohl was macht, nur wird eben net richtig interpretiert, aber dennoch immerhin interpretiert.

i find kein einziges beispiel im netz, wo jemand versucht, in die methode special characters rein zu stopfen... da fehlt mit sicherheit das flag fürs OS: "achtung, sonderzeichen bitte unbearbeitet weitergeben und nicht verarbeiten",...

du meinst also, dass zB bei einem normalen windows-system mit normaler, von mir aus deutscher tastatur, das ganze funktionieren müsste, da es die taste "gibt", und auf dem device, da es die taste nicht nativ und "hard" gibt, nicht?

das kann ich mir net vorstellen, ich seh auch net unterschied net wirklich; wir drücken ja hier ebenfalls einen gewissen shortcut, um zum "[" zu kommen (alt-gr); im wince ist der shortcut halt anders (ich hab netmal den gefunden).
ich find, dass das gar kein so blödes beispiel is mit "["... wichtiger wäre dennoch der dash für meine anwendung.

hast du eSWT und die methode schon mal verwendet und weißt das auch genau?!

okay danke, genau nach sowas hab ich gesucht. ich versuch damit mal meinen java code anzupassen und poste dann, wie weit ich gekommen bin.

achja, wie du auf das mit der eckigen klammer kommst versteh ich net => in der tabelle steht doch nix von taskbar *g, deswegen vermute ich, dass es deine erfahrung is, die du vorher angesprochen hast, oder dass du die hex-werte auswendig samt bedeutung kennst. kannst mir das erklären? das könnt vl wichtig sein für mein verständnis,...

achja, heißt das dann, ich bin mit dem dingsi da auf microsoft plattformen gebunden?

und noch was: weißt du noch, womit du google gefüttert hast? es ärgert mich echt, dass das bei mir net rausgeplumst is, müssen wohl die falschen suchkritierien/-begriffe gewesen sein...

danke jedenfalls!

nach kurzer krank-phase bin i jetzt endlich wieder soweit, mich damit weiter zu beschäftigen.

das mit der eckigen klammer is mir mittlerweile klar, jetzt versteh ich auch, wie das da glesen wird, danke. wenn es um den bindestrich geht, hängt es mich aber schon wieder aus, da ich net weiß, wie ich die tabelle jetzt umsetze oder verwende (siehe code-teil unten).

bezüglich portabilität: da es also diese übersetzungstabelle für sonderzeichen in der klasse SWT (konstanten) offenbar nicht gibt, bin ich da schonmal unportabel

ok ok, dann eben nicht rausgeplumbst. du hast jedenfalls wesentlich mehr hintergrundwissen als ich. danke jedenfalls für die zeit, die du investiert hast, eine halbe stunde is einfach so und für jemanden, den du net kennst, net wenig. danke!

so, bezüglich der implementierung:
ich bin hier leider noch net wirklich weitergekommen; ich versuch mal in worte zu fassen, was ich seit deinem letzten post alles probiert hab (verwendete methoden siehe unten; jetzt verwende ich die aktuellsten sourcen von eSWT => eRCP 1.3):

mit 0xF0 habe ich mir erhofft, dass er mir den modus einfach zu alphanumerisch ändert ("Changes the mode to alphanumeric.") => wie es auch mit "shift" funktioniert, habe ich das auch hier probiert, nur halt dann, wenn wir außerhalb des alphabets sind:

Code:

          if (!(keyCode > 96 && keyCode < 123)) {
            postKeyEvent(display, SWT.KeyDown, 0xf0);
          }
          postKeyEvent(display, SWT.KeyDown, keyCode);
          postKeyEvent(display, SWT.KeyUp, keyCode);
          if !(keyCode > 96 && keyCode < 123)) {
            postKeyEvent(display, SWT.KeyUp, 0xf0);
          }

mit dieser implementierung (die quasi wie eine art maske funktioniert) haut's genauso wenig hin; die taskleise poppt immernoch auf, hier wurde dennoch der character verwendet:

Code:

          if (!(keyCode > 96 && keyCode < 123)) {
            postKeyEvent(display, SWT.KeyDown, character, 0xf0);
            postKeyEvent(display, SWT.KeyUp, character, 0xf0);
          } else {
            postKeyEvent(display, SWT.KeyDown, keyCode);
            postKeyEvent(display, SWT.KeyUp, keyCode);
          }

mit E7 (unicode characters) funktioniert es ebenfalls nicht:

Code:

          // we only take a look at the non capital letters
          if (keyCode > 96 && keyCode < 123) {
            postKeyEvent(display, SWT.KeyDown, keyCode);
            postKeyEvent(display, SWT.KeyUp, keyCode);
          } else {
            postKeyEvent(display, SWT.KeyDown, character, 0xE7);
            postKeyEvent(display, SWT.KeyUp, character, 0xE7);
          }

und das hier leider auch nicht:

Code:

          if (keyCode > 96 && keyCode < 123) {
            postKeyEvent(display, SWT.KeyDown, keyCode);
            postKeyEvent(display, SWT.KeyUp, keyCode);
          } else {
            postKeyEvent(display, SWT.KeyDown, 0xE7);
            postKeyEvent(display, SWT.KeyDown, keyCode);
            postKeyEvent(display, SWT.KeyUp, keyCode);
            postKeyEvent(display, SWT.KeyUp, 0xE7);
          }

die oben verwendeten methoden (ohne character und somit reinem keyCode, wie es der CVS-source auch sagt, und einmal mit character):

mit character und keyCode:

Code:

    public static void postKeyEvent(Display display, int eventType, char character, int keyCode) {
        final Event event = new Event();
        event.type = eventType;
        event.character = character;
        event.keyCode = keyCode;
    }

und einmal ohne character, nur mit keyCode:

Code:

    public static void postKeyEvent(Display display, int eventType, int keyCode) {
        final Event event = new Event();
        event.type = eventType;
        event.keyCode = keyCode;
    }

vielleicht is der source hier eh nutzlos für dich, ich glaub, du kannst mir am ehesten bei der verwendung der konstanten helfen...

wenn ich mir das also so anschaue, dann gibt es jetzt zwei möglichkeiten:
1) ich habe es immernoch net ganz begriffen
2) es geht mit der lösung einfach net so, wie ich das gerne hätte, und ich muss mir einen anderen lösungsweg überlegen.

ich glaub fast, dass es mit der tabelle nicht möglich sein wird, einen bindestrich und weitere sonderzeichen darzustellen. bitte korrigier mich, wenn ich falsch liege. was mich noch fraglich stimmt: windows xp beispielsweise, wo ich dasselbe beispiel probiert hab, postet den bindestrich ohne weiteres handling, als ganz normales zeichen (den code dazu kann i auch gern posten). hier gibt es also offenbar andere virtual key-codes als bei winCE, was ja logisch ist. mit den special virtual key codes bin ich nicht zsammen gekommen bzw. hab kein beispiel gefunden. mir is auch nicht klar, wie das dann ablaufen soll, und ob diese variante überhaupt möglich ist. das da oben ist trial and error, unter verwendung von konstanten, bei denen ich nicht weiß, ob sie die richtigen sind bzw. richtig verwendet werden...

was noch interessant ist: laut dem source im CVS wird das property event.character ignoriert; funktionieren tut es allerdings aber auch damit und also auch so, wie es javadoc sagt: entweder, man setzt den character oder den keyCode, beides funktioniert (http://eclipsesrc.appspot.com/jsrcs...wt/OS.java.html => ist mit sicherheit richtig, sonst würde es nur mit character und ohne keyCode net hinhauen).

danke fürs lesen... ich freu mich über jeden hinweis!