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

Seite 1 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/eswt_display_post_verschluckt_special_characters_a_211966/page_1 - zur Vollversion wechseln!

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);
    }

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

Zitat von that

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

Die sourcen von eSWT sind nicht das problem, die habe ich, zumindest in html-form,... Danke dennoch fuer den link. Ausserdem gibts ja gott sei dank den de-compiler. 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,...

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

tiefer werd ich wohl nicht rankommen. danke für den link; hab gestern genau die sourcen eh schon direkt ausn eclipse CVS auscheckt... bringt mich auch net weiter, vor allem startet der dreck netmal mit den neuen libs, und schmeißt weder exception noch error (throwable)... die JVM schießt sich einfach ab. bin am remote-debuggen...

das is ja net möglich, dass die gschichte mit special chars net umgehen kann, oder? eswt selbst hat mir der anzeige selbst in der GUI ja auch kein problem,...

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

Hat das Zielgerät überhaupt eine "["-Taste?

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

Die Methode, die du verwendest, simuliert das Drücken von Tasten. Die Codes sind also Tastencodes, keine Zeichencodes. Nur "zufällig" stimmen die bei Buchstaben und Ziffern überein.

Wenn es keine "["-Taste gibt, kannst du auch das Drücken dieser Taste nicht simulieren.

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?!

Zitat von sYbb

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?

Zitat von sYbb

wir drücken ja hier ebenfalls einen gewissen shortcut, um zum "[" zu kommen (alt-gr)

Zitat von sYbb

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!

Zitat von sYbb

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

Zitat von sYbb

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

Zitat von sYbb

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

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);
          }

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);
          }

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);
          }

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);
          }

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;
    }

Code:

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

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025