Problem mit Android Barcodescanner

[helste]

Hallo,

ich habe einen Barcodescanner PDA der mit Android 5.1. läuft. Er hat einen eingebauten Scanner, der in der Testapp und in allen apps am PDA problemlos funktioniert. Es wird im Prinzip eine Tastatureingabe simuliert und so der gescannte Code angezeigt.
Nun habe ich eine kleine Testapp mit Firemonkey geschrieben, wo ich ein TEdit auf ein Formular platziert habe und mittels des Scanners Code einscannen und in das TEdit übernehmen möchte.
Der Focus wird auf das TEdit gestellt. Dann scanne ich einen Barcode und es passiert mal nichts. Dann scanne ich nochmal und der Code wird ordnungsgemäß angezeigt. Dann kann ich beliebige Barcodes scannen und es wird auch übernommen, aber immer der als erstes eingescannte Code. Das ist schon mal merkwürdig.
Wenn ich nun aber mittels Hardware oder Softwaretastatur irgendwas eingebe, dann funktioniert das Scannen überhaupt nicht mehr. Das Gerät gibt zwar den Bestätigungston aus, aber es wird kein Code mehr angezeigt.
Bin langsam am Verzweifeln.
Ich verwende Delphi 10.1 Berlin Update 1

Kann mir vielleicht jemand weiter helfen?

Grüße
helmut

[himitsu]

Hast du mal beim Hersteller nachgesehn, ob man den Scanner auch direkt ansprechen kann und dann nicht die Tastaturemulation verwendet?

[helste]

Ja, kann man. Ich habe ein SDK dazu, aber das ist alles Java und da bin ich nicht fit genug dafür. Wollte das einfach in Delphi mit Firemonkey realisieren.

[jaenicke]

Du kannst auch solche SDKs mit Delphi anzusprechen soweit ich weiß. Wieviel Aufwand das ist weiß ich allerdings nicht.

[himitsu]

Delphi Java Bridge
Delphi JNI Bridge

[helste]

Danke. Ich werde mir das mal ansehen. Echt doof, dass man das nicht einfach so verwenden kann, wie es gedacht ist (Keyboard Emulation) und tricksen muss, weil Firemonkey buggy ist. Ich habe auch einen Case bei Embarcadero aufgemacht und schon eine Antwort bekommen. Mal sehen, ob das zu was führt.

[helste]

Achja, in meiner Verzweiflung habe ich mir mal Android Studio angesehen. Habs installiert und ein einfaches Testprojekt gemacht. Damit funktioniert alles sofort auf Anhieb. Ich fürchte aber, dass mir die Einarbeitungszeit zu lang ist um da produktiv damit arbeiten zu können. Lieber wäre mir daher eine Lösung mit Delphi.

[jaenicke]

Zitat:

Zitat von helste (Beitrag 1358837)

Ich habe auch einen Case bei Embarcadero aufgemacht

Ein Link wäre schön, falls mal jemand ein ähnliches Problem hat und diesen Thread findet. ;-)

[helste]

Wenn bei dem case was vernünftiges raus kommt, dann werde ich das hier natürlich posten. Einstweilen gibt es auch noch keine Antwort auf meine weiterführende Beschreibung des Problems.

[himitsu]

Wenn aber in 5 Jahren das doch mal gelöst wird, dann vergisst du bestimmt den Link zu posten.
Daher besser gleich jetzt. Außerdem können dann Andere, welche die selben Probleme haben, dort gleich voten und ebenfalls antworten und damit anzeigen, dass es mehr als nur einen Betroffenen gibt.

[helste]

Das Problem ist, dass man sich in meinem Account anmelden muss, um den Case zu sehen.
Ich denke also nicht, dass es was nützt, wenn ich hier den Link zum Case rein stelle. Ich hoffe auch nicht, dass sich das lange hin zieht. Brauche da eine rasche Lösung, sonst muss ich mich echt noch ins Android Studio einarbeiten.

[himitsu]

Der direkte Weg über die API ist eigentlich (fast) immer der bessere Weg.

So landet die Eingabe immer dort, wo sie hin soll.
Über so Eingabe-Emulationen landet die Eingabe im zufällig aktiven Edit-Control und das muß nicht immer die richtige Stelle sein. :zwinker:


Wenn du direkt englisch mit jemandem quatschst, dann kommt mehr drüben an, als wenn man z.B. noch Google-Translate dazwischenschaltet ... am Besten noch mehrmals über verschiedene Sprachen übersetzt. :angle:

Hier kommt das kleine Problemchen, dass FMX alles selber malt und die Eingaben auch selber behandelt, was nicht immer genauso arbeitet, wie das entsprechende native Control des OS. (abgesehn da, wo Embarcadero es schon geschafft hat, dass man auch in FMX das native Control verwenden kann)

[helste]

Ja, das ist mir schon klar. Wollte es halt möglichst einfach haben.
Was den Focus des Controls anbelangt, so ist der sicher richtig.
Wenn ich den Focus in ein TMemo stelle und den Scanner betätige, dann wird auch in das TMemo der Inhalt des Barcodes eingetragen. Leider halt immer der selbe, nämlich der seit Programmstart als erstes gescannte. Da kann ich dann beliebige Codes scannen, soviel ich will, es wird für jeden Scann immer nur der Inhalt des zuerst gescannten eingetragen. Sobald dann einmal eine Taste gedrückt wurde um was zu löschen oder zu korrigieren, wird gar nichts mehr gescannt. Der Scanner biept zwar, aber es kommt nichts mehr rein.
Das ist definitiv ein Bug und ich werde den Support damit löchern, aber inzwischen muss ich mich nach einer alternativen Lösung umsehen. Da muss ich mich wohl mit der API beschäftigen.
Der Support hat mir auch gleich mal in der ersten Antwort mitgeteilt, dass sie keinen Barcodescanner zum Testen haben. Sehr schwach.

[himitsu]

Nur zur Sicherheit:
In irgendeinem anderem Programm hast du das Scannen auch schonmal probiert?

[helste]

Ja, am Scanner ist ein Demoprogramm zum Scannen und da funktioniert es einwandfrei.

Ich habe zum Scanner ein SDK dazu bekommen mit Testprogramm. Das ist aber alles Java und daher für mich noch etwas ein spanisches Dorf.:oops:

[helste]

achja, und im Webbrowser am Gerät funktioniert das scannen auch einwandfrei.

[DeddyH]

Willkommen in meiner Welt :wink:. Soll Deine App nur diesen einen Scannertypen unterstützen, oder können da auch weitere hinzukommen? Im letzteren Fall viel Spaß, da darfst Du am Ende noch mehrere SDKs einbinden und hast am Ende eine APK von 300 MB oder so und musst dem Benutzer überlassen, welches SDK eigentlich verwendet werden soll. Meine Erfahrungen mit HID-fähigen Scannern sind: mal geht es, mal nicht. Wieso, weshalb, warum, kann ich Dir auch nicht sagen, ich war auch schon öfter am Rande der Tobsucht deswegen. Für die Java-Geschichte kann ich letztendlich nur den Blog von Brian Long empfehlen, der Typ hat es drauf, siehe z.B. hier.

Hth

[helste]

Mir reicht es, wenn dieser Typ unterstützt wird.
Wäre halt schön gewesen, wenn die Firemonkeykomponenten vernünftig funktionieren würden.

Den Brian Long habe ich bei meinen Recherchen entdeckt, aber nicht den Blog, sondern ein Youtube Video
https://www.youtube.com/watch?v=GcuYc7F0lIU

Bin da aber erst bei Minute 15 irgendwo, weil ich permanent was anderes machen muss und dauernd unterbrochen werde.:evil:

Werde mir mal den Blog ansehen. Vielen Dank für den Tipp.

Ich werde aber auch mal mit Embarcadero Deutschland Kontakt aufnehmen. Schließlich haben die bei der letzten Roadshow ja auch wieder vollmundig erklärt, wie einfach und toll das mit dem Firemonkey Framework geht. Nun funktionieren die einfachsten Sachen nicht.
Habe extra auf Berlin upgegradet um das für die mobile Scanner damit einfach machen zu können.

[helste]

Vom Support wurde ich nun gebeten das als bug report zu melden. Das habe ich getan.
Habe halt meinen Support case großteils mit copy and paste übernommen. Hoffe damit fangen die was an und ich hoffe sie tun da was. Wenn das zeitnah gelöst werden könnte, würde ich mir den umständlicheren Weg sparen. Habe nämlich jede Menge anderer Projekte zu erledigen und nicht wirklich Zeit mich damit lange aufzuhalten.

https://quality.embarcadero.com/browse/RSP-16739

Kann vermutlich nur eingesehen werden, wenn man sich anmeldet.

[himitsu]

Achso, als internes Supportdingens wäre die URL eh komisch.
Dachten du hättest es gleich in QC eingetragen.

[helste]

Ich habe es jetzt mal tatsächlich geschafft das SDK, welches ich vom Hersteller bekommen habe, in meine App einzubinden.
Habe eine Java Bridge erstellt und kann die bereitgestellte Klasse auch ansprechen.
Über das OnClick Event eines TButton kann ich nun den Scannvorgang starten. Das war zwar als Test, ob die Implementierung des SDK funktioniert recht nett, aber für meine praktische Anwendung bringt mir das gar nichts.
Schließlich soll der Scan ja durch drücken einer der Hardwarescantasten erfolgen und außerdem hat der Scanner zwar den Barcode gesacannt, das obligatorische Beep von sich gegeben, aber der gescannte code erschien nicht im TMemo, auf den ich den Focus gestellt hatte.
Ehe ich jetzt noch mehr Zeit mit try and error verplempere, werde ich mal warten, was die von Embarcadero zum Firemonkeybug sagen.

[helste]

Ich werde verrückt.
Jetzt habe ich es hinbekommen, dass es funktioniert, aber die Umstände sind merkwürdig und auch unbefriedigend.
Nachdem ich mit dem SDK gespielt hatte, ging plötzlich gar nichts mehr. Auch nicht in der Scanner app, wo es vorher funktioniert hatte. Deshalb habe ich da mal scanner reset ausgeführt. Dann ging es wieder.
Dann klappte es plötzlich in meiner testapp. In einer anderen wieder klappte es nicht. Dann habe ich mich auf die Suche nach dem Unterschied gemacht.
Der war dann darin gelegen, dass ich in einer app im Projektquelltext folgende Zeile hatte:

VKAutoShowMode := TVKAutoShowMode.DefinedBySystem;

und in der anderen

VKAutoShowMode := TVKAutoShowMode.Never;

Im ersten Fall poppt das Softwarekeyboard auf und dann funktioniert auch der Scan.
Im zweiten Fall poppt kein Keyboard auf und der Scan funktioniert nicht.
Blöderweise will ich nicht, dass das Softwarekeyboard aufpoppt, da es mir den halben Screen verdeckt und ich es auch gar nicht brauche, da die Daten per Barcode kommen bzw. über die Hardwaretastatur eingegeben werden können.

In der Scannerapp des Gerätes funktioniert der Scan in beiden Fällen. Sollte also grundsätzlich möglich sein.

Werde das Embarcadero auch so mitteilen.

Bei der Gelegenheit suche ich nun auch nach einer Möglichkeit das Softwarekeyboard nicht standardmäßig aufzumachen, wenn ein Eingabefeld den Focus bekommt, sondern allenfalls das Aufpoppen des Keyboards durch den Anwender initiiert werden kann, in welcher Form auch immer.

[helste]

Falls es interessiert, ich habe einen Workaround gefunden.

Habe diesen Thread entdeckt:
http://www.delphipraxis.net/186005-v...ktivieren.html

Ich habe nun die unit VirtualKeyboardService erstellt und in meine Testapp eingebunden.

Die Methoden ShowVirtualKeyboard und HideVirtualKeyboard habe ich allerdings public declariert, damit ich sie auch aufrufen kann.

ShowVirtualKeyboard habe ich leicht modifiziert, damit ich notfalls doch das Keyboard anzeigen kann. Zu diesem Zweeck muss ich vor dem Aufruf von ShowVirtualKeyboard das Tag des Editcontrols auf <> 0 setzen.

Code:

function TVirtualKeyboardService.ShowVirtualKeyboard( const AControl: TFmxObject ): Boolean;
begin
  if IsOverriddenObject( AControl ) and (acontrol.Tag = 0) then
  begin
    HideVirtualKeyboard;
    Result := False;
  end
  else
    Result := FOriginalService.ShowVirtualKeyboard( AControl );
end;

Meinem TEdit habe ich einen Button verpasst in dessen OnClick ich Tag mit 0 oder 1 versorge. Dadurch kann ich mit dem Button das Keyboard sichtbar oder unsichtbar machen.

Code:

procedure TForm1.EditButton1Click(Sender: TObject);
begin
Edit1.Tag := abs (Edit1.Tag - 1);
if Edit1.Tag = 0 then
   TVirtualKeyboardService.Current.HideVirtualKeyboard
else
   TVirtualKeyboardService.Current.ShowVirtualKeyboard(Edit1);
end;

Im OnEnter setze ich Tag immer auf 0;

Das funktioniert erst mal ganz vernünftig. Einziges Problem ist noch, dass der erste Scan nur funktioniert, wenn einmal ein Keyboard angezeigt wurde.

Habe deshalb mal Edit1.Tag im Formshow auf -1 gesetzt und im OnEnter von Edit1 im Falle, dass Tag < 0 ist, das Keyboard einmal angezeigt und gleich wieder geschlossen.

Code:

procedure TForm1.FormShow(Sender: TObject);
begin
Edit1.Tag := -1;
end;

procedure TForm1.Edit1Enter(Sender: TObject);
begin
if Edit1.Tag < 0 then
   begin
   TVirtualKeyboardService.Current.ShowVirtualKeyboard(Edit1);
   TVirtualKeyboardService.Current.HideVirtualKeyboard;
   end;
Edit1.Tag := 0;
end;

Das funktioniert so, ist aber nicht befriedigend, da es nicht sehr schön ist, wenn das Keyboard kurz angezeigt wird.
Da ich in der richtigen App aber ohnehin zu Beginn eine Login Maske habe und man da sowieso sinnvollerweise ein Keyboard benötigt (und es da auch nicht stört), kann ich mir das dann da eventuell ersparen.

Irgendwie ziemlich kompliziert nur für so eine einfache Funktion. Aber was solls, Hauptsache es funktioniert.

Wäre aber trotzdem für Anregungen, Verbesserungsvorschläge und Hinweise auf eventuelle Fallstricke bzw. Denkfehler dankbar.

[hstreicher]

Bin neugierig , aber evtl hab ich es auch überlesen ,
aber welcher Scanner ist es denn Hersteller / Modell

mfg Hannes

[helste]

Es ist dieser Scanner:
http://www.ruggedscanners.com/obm-a5...-p00017p1.html

Habe ihn aus China importiert. Das Teil ist sehr ansprechend. Super look and feel. Bin damit sehr zufrieden. Ist mal ein Test für weitere um sie dann für Lagerwirtschaft einzusetzen.

Übrigens habe ich nun eine deutlich einfachere Lösung meines Problems gefunden. Kommt ohne die unit VirtualKeyboardService aus.

Zuerst setze ich im Projektquelltext wieder

VKAutoShowMode := TVKAutoShowMode.Never;

Dadurch entfällt das umständliche Unsichtbarmachen des Keyboards.
In der Loginmaske setze ich bei den Eingabefeldern das OnEnter wie folgt:

Delphi-Quellcode:

procedure TForm1.Edit1Enter(Sender: TObject);

var
   FService: IFMXVirtualKeyboardService;

begin
TPlatformServices.Current.SupportsPlatformService(IFMXVirtualKeyboardService, IInterface(FService));
if (FService <> nil) then
   begin
   FService.ShowVirtualKeyboard(Edit1);
   Edit1.SetFocus;
   end;
end;

Dadurch wird schon mal die Tastatur erstmalig sichtbar und dadurch wird in weiterer Folge der Scanvorgang erst richtig möglich.

Das OnEnter aller Felder, die kein Keybord benötigen, bzw. wo es nicht angezeigt werden soll, sieht so aus:

Delphi-Quellcode:

procedure TForm1.Edit2Enter(Sender: TObject);

var
   FService: IFMXVirtualKeyboardService;

begin
TPlatformServices.Current.SupportsPlatformService(IFMXVirtualKeyboardService, IInterface(FService));
if (FService <> nil) then
   FService.HideVirtualKeyboard;
TEdit (Sender).Tag := 0;
end;

Jedes dieser Eingabefelder bekommt aber einen Button, über den man das Keyboard anzeigen kann. Eventuell checke ich mal, ob das nicht besser über eine Hardwarteste des Scanners erledigt werden sollte. Dann halt im OnKeUp des Eingabefeldes.
Einstweilen aber mal so:

Delphi-Quellcode:

procedure TForm1.EditButton1Click(Sender: TObject);

var
   FService: IFMXVirtualKeyboardService;

begin
Edit2.Tag := abs (Edit2.Tag - 1);
TPlatformServices.Current.SupportsPlatformService(IFMXVirtualKeyboardService, IInterface(FService));
if (FService <> nil) then
   begin
   if Edit2.Tag = 0 then
      FService.ShowVirtualKeyboard(Edit2)
   else
      FService.HideVirtualKeyboard;
   Edit2.SetFocus;
   end;
end;

Funktioniert hervorragend so.
Zumindest nach ersten kurzen Tests.

[himitsu]

Zitat:

Zitat von helste (Beitrag 1359028)

Ich habe es jetzt mal tatsächlich geschafft das SDK, welches ich vom Hersteller bekommen habe, in meine App einzubinden.
Habe eine Java Bridge erstellt und kann die bereitgestellte Klasse auch ansprechen.
Über das OnClick Event eines TButton kann ich nun den Scannvorgang starten. Das war zwar als Test, ob die Implementierung des SDK funktioniert recht nett, aber für meine praktische Anwendung bringt mir das gar nichts.
Schließlich soll der Scan ja durch drücken einer der Hardwarescantasten erfolgen und außerdem hat der Scanner zwar den Barcode gesacannt, das obligatorische Beep von sich gegeben, aber der gescannte code erschien nicht im TMemo, auf den ich den Focus gestellt hatte.

Wenn du das so machst, müsste es in der API eine Methode/Event geben, welche dir den Code "im Programm" gibt und dann kannst du den eingelesenen Code in das gewünschte Edit einfügen.

Wenn es einen Hardwarebutton gibt, dann kann man diesen bestimmt auch via API/SDK ansprechen, bzw. ein Event dafür registrieren.

[helste]

Ja, aber leider ist die Doku des SDK etwas rudimentär gehalten bzw. kenne ich mich da zu wenig damit aus.
Meine andere Lösung funktioniert aber schon mal recht gut. Bin gerade am testen, ob es wirklich in allen Fällen so tut, wie ich will.