Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > Non-English Discussions > Deutsches Forum > PocketBook

Notices

Reply
 
Thread Tools Search this Thread
Old 08-27-2013, 08:01 PM   #1
jtt
Connoisseur
jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.
 
Posts: 97
Karma: 90350
Join Date: Aug 2013
Location: Berlin, Germany
Device: PB 622, PB 623
Dokumentation der PocketBook SDK

Hallo,

ich bin gerade dabei zu versuchen erste Programme für mein PB622 und PB623 zu schreiben. Nach ziemlicher Sucherei habe ich anscheindend endlich eine halbwegs funktionierende SDK ("sdkrelease_1.0.tar.gz" für Linux, die wohl aus dem Jahre 2011 stammt) gefunden. Leider enthält diese nicht das geringste Bischen an Dokumentation. Zwar gibt es ein paar Beispielprogramme und, mit etwas Phantasie, kann man bei einigen Sachen raten, wozu die Funktionen usw. vielleicht gut sind, aber das hilft nur sehr bedingt weiter.

Bei der Suche nach mehr Dokumentation habe ich einen PDF-File mit Dokumentation gefunden, wo eine Revisionsnummer 1.05 drinnen steht. Ein paar Sachen sind dadurch klarer geworden (insbesondere, dass ein nicht unerheblicher Teil der Funktionen aus inkview.h "deprectated" ist;-), aber vieles ist auch darin nicht dokumentiert.

Mein erstes Programm war eines, dass einfach nur ausgab, welche events (und Parameter) die InkViewMain() übergebene handler-Funktion erhält. Dabei musste ich feststellen, dass einige der events (z.B. 39, 151, 152) nicht einen in inkview.h definierten Namen haben. Dokumentiert ist selbst von den in inkview.h zu findenden Funktionen, zumindest soweit ich es bisher herausfinden konnte, nur ein Bruchteil. Zum Teil scheint auch die Dokumentation, die ich schliesslich gefunden habe, auch nicht mit den Sachen aus inkview.h kongruent zu sein - z.b. finden sich manche der Dokumentation erwähnten events wiederum nicht in inkview.h.

Weiss vielleicht jemand, wo genau man die derzeit aktuellen Versionen der SDK und der Dokumentation finden kann, vielleicht sogar Versionen, die halbwegs zusammenpassen?

MfG, Jens
jtt is offline   Reply With Quote
Old 08-30-2013, 06:30 AM   #2
MartinZ
Zealot
MartinZ doesn't litterMartinZ doesn't litter
 
Posts: 110
Karma: 138
Join Date: Mar 2011
Device: PB903, PB603
Dokumentation SDK

Hallo Jens,

http://code.google.com/p/libinkviewdoc/source/browse/

Vor dem Problem stehen wir ja alle.
Daher haben Sergey Vlasov und ich mal unsere Erkenntnisse im Doxygen-Format in die inkview.h eingebaut und (siehe obigen Link) online gestellt.
Es wäre schön, wenn alle, die am PB entwickeln, daran mitarbeiten würden.
Bisher haben aber nur Sergey und ich mal was reingestellt.

Übrigens hat mir zum Einstieg Sergeys Video für die Eclipse-Einbindung geholfen (seither macht es viel mehr Spaß...)

http://pbsdk.vlasovsoft.net/videos.html
MartinZ is offline   Reply With Quote
Old 09-01-2013, 05:37 PM   #3
jtt
Connoisseur
jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.
 
Posts: 97
Karma: 90350
Join Date: Aug 2013
Location: Berlin, Germany
Device: PB 622, PB 623
Hallo Martin,

vielen Dank für deine Antwort! Ich bin natürlich auch an einer verbesserten Dokumentation interessiert, weiss aber nicht, ob ich mit meiner bisher minimalen Erfahrung allzuviel beitragen kann. Als Anfang vielleicht drei Sachen, die ich in den letzten Tagen gefunden habe:

a) OpenFont() scheint wider Erwarten niemals NULL zurückzuliefern, selbst wenn man einen nicht-existierenden Fontnamen übergibt. Der falsche Name steht dann sogar im 'name' Feld der ifont structure, tatsächlich wird aber anscheinend ein Default-Font verwendet.

b) Ich habe mal mit OpenDirectorySelector() herumprobiert und musste feststellen, dass da zwar was wenig bedienbares auf dem Display erschien, jede Interaktion damit aber zum sofortigen Absturz des Programm führte. Ein auf die Dauer sinnvolles Projekt könnte vielleicht sein einen funktionierenden File- und Directory-Selector zu schreiben.

c) Bei der imenu structure hat das 'text' Feld den Type 'char *'. Ich hoffe sehr, dass das eigentlich ''char const *' sein sollte, denn anderenfalls dürfte man dafür keine string literals verwenden (was aber bei allen Beispielprogrammen, die ich gesehen habe, gemacht wird)...

Ich wäre auch neugierig, wo der 'inkview.h' File, der bei eurem Dokumentationsprojekt steht, herstammt - meiner sieht etwas anders aus (einige Sachen fehlen). Habt ihr den ergänzt oder gibt es vielleicht eine neuere Version der SDk, die ich noch nicht gefunden habe?

Am besten wäre natürlich eine vollständige Dokumentation durch die Autoren der Library - Ratespiele sind natürlich ganz nett und leider manchmal auch der einzige Weg, aber man läuft immer in die Gefahr, dass man nur das tatsächliche Verhalten dokumentiert, nicht aber das vom Autor der Library intendierte - und dass dann nach dem nächsten Bug-Fix wieder einiges nicht mehr stimmt...

Wenn du willst kannst du mich gerne auch per Email erreichen, sie ist jt@toerring.de (falls die von der Foren-Software nicht durchgelassen wird findest du sie auch auf meiner Homepage, die in meinem Profil steht).

Herzliche Grüße, Jens

PS: Mit Eclipse habe ich nicht so schrecklich viel am Hut, ich bin alter Emacser, aber ohne missionarische Ambitionen;-)
jtt is offline   Reply With Quote
Old 09-06-2013, 01:11 PM   #4
MartinZ
Zealot
MartinZ doesn't litterMartinZ doesn't litter
 
Posts: 110
Karma: 138
Join Date: Mar 2011
Device: PB903, PB603
SDK

Quote:
a) OpenFont() scheint wider Erwarten niemals NULL zurückzuliefern, selbst wenn man einen nicht-existierenden Fontnamen übergibt. Der falsche Name steht dann sogar im 'name' Feld der ifont structure, tatsächlich wird aber anscheinend ein Default-Font verwendet.
Ja, das stimmt. Habe ich auch festgestellt. Bei nicht existierendem Fontnamen sucht Openfont wohl selbst einen Default-Font. Ob es aber wirklich niemals NULL zurückgibt, ist nicht erwiesen...

Ich habe normalerweise so etwas eingebaut:

Code:
if(pFont!=NULL)
			{
				CloseFont(pFont);
				pFont=NULL;
			}
			pFont = OpenFont(DEFAULTFONT, 15, 0);
Irgendwie erinnere ich mich, dass wegen falschem Umgang mit Fonts ich erst viele Abstürze hatte. Hier ein entsprechender Kommentar aus meinem PBChord-Programm:

Code:
//ifont *vorher = GetFont();   //I wanted to save actual font during examining width
			//But storing the result of GetFont() crashes on real device (not in Emulator)
Versuche also niemals, den Rückgabewert von GetFont abzuspeichern! Das Gibt sofortigen Absturz auf PB903/603 aber nicht auf dem Emulator...



Quote:
b) Ich habe mal mit OpenDirectorySelector() herumprobiert und musste feststellen, dass da zwar was wenig bedienbares auf dem Display erschien, jede Interaktion damit aber zum sofortigen Absturz des Programm führte. Ein auf die Dauer sinnvolles Projekt könnte vielleicht sein einen funktionierenden File- und Directory-Selector zu schreiben.
Den gibt es schon. Ich habe ihn bei PBChord benutzt. Er stammt aus der PBTK-Bibliothek, die der Autor von "Pi", dem Texteditor zur Verfügung gestellt hat. Es hat mich zwar einige graue Haare gekostet, die "from source" zu builden, da er Smart-Pointer aus der Boost-Bibliothek verwendet - aber sie lief dann doch irgendwann.

Quote:
c) Bei der imenu structure hat das 'text' Feld den Type 'char *'. Ich hoffe sehr, dass das eigentlich ''char const *' sein sollte, denn anderenfalls dürfte man dafür keine string literals verwenden (was aber bei allen Beispielprogrammen, die ich gesehen habe, gemacht wird)...
Es ist aber wohl als char * deklariert:

Code:
typedef struct imenu_s {

	short type;
	short index;
	char *text;
	struct imenu_s *submenu;
} imenu;
Im PBTK nutzt der Autor es folgendermaßen:

Code:
std::vector<std::string>::iterator it=items.begin();
    for(int i=0;i<(int)items.size();++i,++it){
      menu[ms-i-1].type=ITEM_ACTIVE;
      menu[ms-i-1].index=i;
      menu[ms-i-1].text=(char*)it->c_str();
    }
Quote:
Ich wäre auch neugierig, wo der 'inkview.h' File, der bei eurem Dokumentationsprojekt steht, herstammt - meiner sieht etwas anders aus (einige Sachen fehlen). Habt ihr den ergänzt oder gibt es vielleicht eine neuere Version der SDk, die ich noch nicht gefunden habe?
Ich meine, das wäre von Sergej's PBSDK
Ich hatte aber auch noch inkinternal.h dazu genommen - auch wenn man das wahrscheinlich kaum brauchen wird.

Quote:
Am besten wäre natürlich eine vollständige Dokumentation durch die Autoren der Library - Ratespiele sind natürlich ganz nett und leider manchmal auch der einzige Weg, aber man läuft immer in die Gefahr, dass man nur das tatsächliche Verhalten dokumentiert, nicht aber das vom Autor der Library intendierte - und dass dann nach dem nächsten Bug-Fix wieder einiges nicht mehr stimmt...
Natürlich. Aber ich glaube kaum, dass wir die jemals bekommen werden

Gruß,
Martin
MartinZ is offline   Reply With Quote
Old 09-06-2013, 05:03 PM   #5
jtt
Connoisseur
jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.
 
Posts: 97
Karma: 90350
Join Date: Aug 2013
Location: Berlin, Germany
Device: PB 622, PB 623
Hallo Martin,

Quote:
Ja, das stimmt. Habe ich auch festgestellt. Bei nicht existierendem Fontnamen sucht Openfont wohl selbst einen Default-Font. Ob es aber wirklich niemals NULL zurückgibt, ist nicht erwiesen...
Ja, endgültige Aussagen kann man durch Raten leider nie hinkriegen;-)

Quote:
Irgendwie erinnere ich mich, dass wegen falschem Umgang mit Fonts ich erst viele Abstürze hatte. Hier ein entsprechender Kommentar aus meinem PBChord-Programm:

Code:
//ifont *vorher = GetFont();   //I wanted to save actual font during examining width
			//But storing the result of GetFont() crashes on real device (not in Emulator)
Versuche also niemals, den Rückgabewert von GetFont abzuspeichern! Das Gibt sofortigen Absturz auf PB903/603 aber nicht auf dem Emulator...
Das wundert mich eigentlich nicht so sehr, ein so zurückgegebener Pointer ist in aller Regel nur solange gültig, bis die Funktion das nächste Mal aufgerufen wird. Wenn man die Informationen, auf die ein solcher Pointer zeigt, später noch braucht, muss man immer eine "deep copy" machen. Dass sich das Verhalten auf dem Gerät und dem Emulator unterscheidet könnte an unterschiedlichen memory allocation Strategien liegen sofern der Pointer nicht z.B. auf eine als in der GetFont() Funktion als static definierte structure zeigt (in dem Fall würde ich dann aber eher erwarten, dass die Verwendung eines "alten" Pointers nicht zu Abstürzen führt, sondern nur zu scheinbar unsinnigen Inhalten).

Quote:
Den gibt es schon. Ich habe ihn bei PBChord benutzt. Er stammt aus der PBTK-Bibliothek, die der Autor von "Pi", dem Texteditor zur Verfügung gestellt hat. Es hat mich zwar einige graue Haare gekostet, die "from source" zu builden, da er Smart-Pointer aus der Boost-Bibliothek verwendet - aber sie lief dann doch irgendwann.
Vielen Dank für den Hinweis, ich werde mal versuchen das zu finden.

Quote:
Es ist aber wohl als char * deklariert:

Code:
typedef struct imenu_s {

	short type;
	short index;
	char *text;
	struct imenu_s *submenu;
} imenu;
Das war ja gerade meine Kritik daran, ich würde da gerne einen 'char const *' für das 'text' Feld haben;-)

Quote:
Im PBTK nutzt der Autor es folgendermaßen:

Code:
std::vector<std::string>::iterator it=items.begin();
    for(int i=0;i<(int)items.size();++i,++it){
      menu[ms-i-1].type=ITEM_ACTIVE;
      menu[ms-i-1].index=i;
      menu[ms-i-1].text=(char*)it->c_str();
    }
Klar, die const-ness weg-casten kann man immer (und ich habe das auch erst mal so gemacht in der Hoffnung, dass das 'const' da nur vergessen wurde). Aber ein const Pointer beinhaltet ja das Versprechen, dass das, was auch immmer den string kriegt, dessen Inhalt nicht zu ändern versuchen wird. Aber wenn ich mich nicht darauf verlassen kann ist das Weg-casten der const-ness ein Vabanque-Spiel - wenn die Funktion den nicht als const gekennzeichneten String tatsächlich verändern sollte hat man ein ernsthaftes Problem. In dem obigen Beispiel würde die C++-String ohne deren Wissen geändert, und das führt zu sehr unschönen Effekten (Absturz im besten Falle und unbemerkte Datenkorruption im unangenehmeren - und manchmal wird's auch so aussehen als wäre alles wunderbar). Und wenn man da ein string literal übergibt, dann knallt's entweder oder man hat zumindest undefined behaviour, je nach Plattform...
Etwas mehr Sauberkeit bei der Arbeit wäre schon erfreulich, da es allen Beteiligtem, inklusive den Autoren, auf die Dauer einen Haufen Arbeit und Kopfzerbrechen ersparen kann.

Quote:
Ich meine, das wäre von Sergej's PBSDK
Danke, die kannte ich auch noch nicht!

Quote:
Natürlich. Aber ich glaube kaum, dass wir die jemals bekommen werden
Wirklich schade. Mir ist nicht so ganz einsehbar, warum man sich die Arbeit macht eine Library zu schreiben, die man dann nicht dokumentiert und sie damit zumindest halbwegs unbenutzbar macht. Ich habe selbst schon einige Libraries geschrieben und weiss deshalb natürlich, dass dann auch noch Dokumentation zu schreiben nicht gerade der leckerste Teil der Arbeit ist. Andererseits hat es sich eigentlich immer dadurch bezahlt gemacht, dass ich durch das nochmal gründlich darüber Nachdenken und auch immer mal wieder Nachkontrollieren, was man da eigentlich wirklich zusammengebastelt hat, einiges an Fehlern und sogar Design-Probeme gefunden habe. Na ja...
Vielleicht kann man sie ja dazu bewegen die Sourcen für die Library rauszurücken, dann könnte man sich, ganz unabhängig von der Dokumentation, ein Bild machen (und vielleicht auch sogar zur deren Verbesserung beitragen).

Freundliche Grüße, Jens

Last edited by jtt; 09-06-2013 at 05:08 PM.
jtt is offline   Reply With Quote
Old 09-07-2013, 07:09 AM   #6
MartinZ
Zealot
MartinZ doesn't litterMartinZ doesn't litter
 
Posts: 110
Karma: 138
Join Date: Mar 2011
Device: PB903, PB603
SDK

Quote:
Quote:
Irgendwie erinnere ich mich, dass wegen falschem Umgang mit Fonts ich erst viele Abstürze hatte. Hier ein entsprechender Kommentar aus meinem PBChord-Programm:

Code:
//ifont *vorher = GetFont(); //I wanted to save actual font during examining width
//But storing the result of GetFont() crashes on real device (not in Emulator)
Versuche also niemals, den Rückgabewert von GetFont abzuspeichern! Das Gibt sofortigen Absturz auf PB903/603 aber nicht auf dem Emulator...
Das wundert mich eigentlich nicht so sehr, ein so zurückgegebener Pointer ist in aller Regel nur solange gültig, bis die Funktion das nächste Mal aufgerufen wird. Wenn man die Informationen, auf die ein solcher Pointer zeigt, später noch braucht, muss man immer eine "deep copy" machen. Dass sich das Verhalten auf dem Gerät und dem Emulator unterscheidet könnte an unterschiedlichen memory allocation Strategien liegen sofern der Pointer nicht z.B. auf eine als in der GetFont() Funktion als static definierte structure zeigt (in dem Fall würde ich dann aber eher erwarten, dass die Verwendung eines "alten" Pointers nicht zu Abstürzen führt, sondern nur zu scheinbar unsinnigen Inhalten).
Wie schön, dass sich mal jemand mit Pointern und ihren Tücken auskennt... Meist versteht mich keiner, wenn ich von so etwas rede

Für mich wäre es eigentlich auch keine Überraschung gewesen, dass man sich auf den zurückgegebenen Wert nicht verlassen darf.
Aber der Absturz passierte (glaube ich) überraschenderweise nicht beim Benutzen des zurückgegebenen Pointers, sondern direkt schon in der Zuweisungszeile:
Code:
ifont *vorher = GetFont();
Also einfach durch das Abspeichern der Adresse. Schon diese Zeile führte zum Crash und das hatte mich überrascht.

Möglicherweise arbeitet GetFont() intern mit einer Referenzverwaltung, die das Eigentum am Speicher, auf den der Zeiger zeigt bei der Zuweisung abgibt, so dass dann GetFont und seine Kollegen intern nichts mehr zu bestellen haben.
Es gibt ja solche "ScopedPointer" und andere Schweinereien...

Die Sache mit dem char * im imenu könnte ja auch darauf hinweisen, dass der Member "text" nicht nur als Eingabe gedacht ist, sondern auch veränderlichen Text enthalten kann (wer auch immer den dann nachträglich verändern können sollte).
MartinZ is offline   Reply With Quote
Old 09-07-2013, 10:14 AM   #7
jtt
Connoisseur
jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.
 
Posts: 97
Karma: 90350
Join Date: Aug 2013
Location: Berlin, Germany
Device: PB 622, PB 623
Hallo Martin,

Quote:
Wie schön, dass sich mal jemand mit Pointern und ihren Tücken auskennt... Meist versteht mich keiner, wenn ich von so etwas rede
Na ja, wer die nach einigen Jahren Programmieren in C und C++ nicht kennt sollte sich ganz dringend einen anderen Job suchen;-)

Quote:
Für mich wäre es eigentlich auch keine Überraschung gewesen, dass man sich auf den zurückgegebenen Wert nicht verlassen darf.
Aber der Absturz passierte (glaube ich) überraschenderweise nicht beim Benutzen des zurückgegebenen Pointers, sondern direkt schon in der Zuweisungszeile:
Also einfach durch das Abspeichern der Adresse. Schon diese Zeile führte zum Crash und das hatte mich überrascht.
Das ist dann allerdings merkwürdig! Das einzige, was mir spontan einfällt ist eine obskure Ecke des C-Standards, die besagt, dass allein schon die Verwendung eines Pointers auf ein nicht mehr existierenden Objekt undefined behaviour hervorruft. Damit ist tatsächlich bereits so etwas scheinbar harmloses wie

Code:
int * p = malloc( 10 );
free( p );
printf( "%p\n", ( void * ) p );
im Prinzip nicht koscher (der Aufruf von free() kann aus der im Pointer gespeicherten Addresse - ohne diese zu ändern! - eine sogenannte "trap representation" machen). Ich habe allerdings noch nie eine Plattform gesehen, bei der dies tatsächlich zu Problemen führte - aber vielleicht sind die ARM-Architekturen ja das erste Beispiel. Das würde aber gleichzeitig erfordern, dass GetFont() einen ungültigen Pointer zurückliefert - was wiederum der Fall sein könnte, wenn sie einen Pointer auf eine lokale (non-static) strucure oder einen lokalen scoped_ptr zurückgibt und da jemand nicht auf die Compiler-Warnungen gehört hat, dass das unsinnig ist. Aber das sind natürlich alles nur wilde Spekulationen...

Quote:
Die Sache mit dem char * im imenu könnte ja auch darauf hinweisen, dass der Member "text" nicht nur als Eingabe gedacht ist, sondern auch veränderlichen Text enthalten kann (wer auch immer den dann nachträglich verändern können sollte).
Ich vermute, du denkst da z.B. an automatische Übersetzungen. Aber in dem Fall macht das wenig Sinn, da aus dem 'text' Pointer nicht ersichtlich ist, wieviel Speicher für den String zur Verfügung steht und man sich nur am '\0' am Ende orientieren kann, d.h. der übersetzte Text dürfte nie länger sein als der Originaltext. Und den 'text' Pointer auf was anderes umzubiegen ist ja auch dann kein Problem, wenn es ein 'char const *' ist - das wäre es nur bei einem 'char * const'. Ich vermute, dass dem Autor der Unterschied zwischen den beiden nicht so ganz klar war und er/sie deshalb das 'const' lieber ganz weggelassen hat;-)

Freundliche Grüße, Jens
jtt is offline   Reply With Quote
Old 09-12-2013, 09:43 AM   #8
jtt
Connoisseur
jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.
 
Posts: 97
Karma: 90350
Join Date: Aug 2013
Location: Berlin, Germany
Device: PB 622, PB 623
Keyboard Funktionen

Hallo Martin,

ich habe vielleicht eine Information für euer Dokumentationsprojekt:

a) Das der Funktion OpenKeyboard() übergebene Argument 'maxlen' ist nicht, wie man eigentlich erwarten würde, die Länge des per Argument 'buffer' übergebenen Buffers, sondern es scheint sich um die Maimalzahl der Zeichen, die eingegeben werden kann, zu handeln. Darüber hinaus scheint die Funktion einen Bug zu haben, da man nämlich einen Buchstaben mehr als über 'maxlen' angegeben eingeben kann (und dieser "überschüssige" Buchstabe wird auch in den Buffer geschrieben). Da intern anscheinend UTF-8 verwendet wird, und jedes Zeichen also bis zu 4 Bytes erfordern kann, muss man den Buffer so dimensionieren, dass er Platz für '4+(maxlen+1)+1' Bytes hat, wenn man sicherstellen will, dass es keine buffer overruns geben kann.

Interessanterweise beschneidet die Funktion den Inhalt des ihr übergebenen Buffers, wenn man ihn mit zuvielen Zeichen initialsiert hat, auf maxlen-1 Zeichen...

b) Es gibt (zumindestens in meiner Version) in der Library eine Funkton namens DrawCircleLine() (die im Header-File allerdings nicht auftaucht). Sie hat, soweit ich durch Ausprobieren herausfinden konnte, die Signatur

Code:
void DrawCircleLine(int x1, int y1, int x2, int y2, int width, int color);
und zeichnet eine Linie von (x1,y1) nach (x2,y2) mit einer Breite von 'width'. Die Enden der Linie sollen anscheinend Halbkreise (am den jeweiligen Punkt zentriert) sein - sieht bei nicht zu breiten Linien auch ha;bwegs brauchbar aus, bei breiteren Linien scheinen es eher Dreiecke am Ende zu sein...

c) Wenn man den Finger über den Bildschirm zieht bekomt man zusätzlich zu den dokumentierten Events zwei weitere Typen, nämich gelegentlich einen 'EVT_POINTERDRAG' (Wert 44), der als 'par1' und 'par2' die gleichen Koordiaten anzeigt, wie der vorher gesendete 'EVT_POINTERMOVE', sowie, häufiger, einen 'EVT_MTSYNC' (Wert 39), dessen 'par1' immer 2 zu sein scheint, während 'par2' 1 ist, wenn man nur einen Finger verwendet, aber 2, wenn man zwei (oder mehr) Finger gleichzeitig auf dem Touchscreen hat. Die spannende Frage ist dann natürlich, wie man herausfindet, wo sich der zweite Finger befindet, so dass man multi-touch guestures in seinen Programmen verwenden kann.

Weisst du übrigens, wer für die originale SDK von pocketbook-free.sourceforge.net verantwortlich ist bzw. wer die Ansprechpartner sind? Ich kann da auf der Seite nichts finden (und Russisch, das im Forum benutzt wird, kann ich keider nicht).

Freundliche Grüße, Jens

Last edited by jtt; 09-16-2013 at 08:22 AM.
jtt is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Official SDK from PocketBook sergeyvl12 PocketBook Developer's Corner 93 09-14-2023 07:21 AM
Pocketbook in der Schweiz prafamod PocketBook 0 02-01-2012 03:45 AM
Pocketbook free SDK in Cooler ereader racagalro PocketBook 0 11-13-2010 12:03 PM
Dokumentation Pocketbook alfix PocketBook 2 10-20-2010 01:53 PM
Pocketbook SDK, Linux and Wine mikmak PocketBook 10 12-09-2009 06:17 AM


All times are GMT -4. The time now is 04:51 AM.


MobileRead.com is a privately owned, operated and funded community.