Qt-interest Archive, April 2008
QItemDelegate QLineEdit problem
Message 1 in thread
Hello,
i have a QTableView using QItemDelegate to edit the first column of every row, here i read a ean13 code and
loads in the model (a subclass of QAbstractTableModel) all the columns information from a sql call in an
internal list that i show with data, the problem i have it is i am using a barcode reader and if i do the
reads too fast the delegate QLineEdit seems to not catch the enter key send by the barcode reader, or maybe it
get it too late, i will try to explain here:
-first ean13 6361324116001
-second ean13 4088885000328
-third ean13 0292430300229
if i read too fast with the barcode reader i get for example:
63613241160014088885000328 (the two first ean13 complete), i have fixed this behaviour when the string % 13 ==
0 but other times i get:
636132411600140888 and in the next row 5000328 so i dont know how to fix this, if the computer running the
program it is really fast (Core2 Duo E6600 for example) it begins to be hard to see the error but all the
machine running the program are Pentium 4 < 2ghz or celeron and they are very easy to make fail. How i can fix
this?
--
[ signature omitted ]
Message 2 in thread
On Monday 14 April 2008 19:35:23 Linos wrote:
> Hello,
> i have a QTableView using QItemDelegate to edit the first column of every
> row, here i read a ean13 code and loads in the model (a subclass of
> QAbstractTableModel) all the columns information from a sql call in an
> internal list that i show with data, the problem i have it is i am using a
> barcode reader and if i do the reads too fast the delegate QLineEdit seems
> to not catch the enter key send by the barcode reader, or maybe it get it
> too late, i will try to explain here:
>
> -first ean13 6361324116001
> -second ean13 4088885000328
> -third ean13 0292430300229
>
>
> if i read too fast with the barcode reader i get for example:
>
> 63613241160014088885000328 (the two first ean13 complete), i have fixed
> this behaviour when the string % 13 == 0 but other times i get:
>
> 636132411600140888 and in the next row 5000328 so i dont know how to fix
> this, if the computer running the program it is really fast (Core2 Duo
> E6600 for example) it begins to be hard to see the error but all the
> machine running the program are Pentium 4 < 2ghz or celeron and they are
> very easy to make fail. How i can fix this?
Yeah had the same issue, but i blame the scanner. usually keycodes dont
get "lost".
I am pretty sure that's not a Qt issue. Try subclassing QLineEdit and log the
keyPressEvent. You'll see some losses too. blame the scanner manufactor of
the people who HAVE to use polling for every shit they write no matter how
often you tell them it's a broken concept.
Note that some scanners can be configured to type slower. which makes working
with them kinda anoying but thats fortunatly not my problem :P
--
[ signature omitted ]
Message 3 in thread
but if i read at the same speed in a text editor or a console window i have not the problem, even the older
clipper dos program running in dosemu doesnt have the problem, it should be a qt problem i think.
Regards,
Miguel Angel.
Arvid Ephraim Picciani escribió:
> On Monday 14 April 2008 19:35:23 Linos wrote:
>> Hello,
>> i have a QTableView using QItemDelegate to edit the first column of every
>> row, here i read a ean13 code and loads in the model (a subclass of
>> QAbstractTableModel) all the columns information from a sql call in an
>> internal list that i show with data, the problem i have it is i am using a
>> barcode reader and if i do the reads too fast the delegate QLineEdit seems
>> to not catch the enter key send by the barcode reader, or maybe it get it
>> too late, i will try to explain here:
>>
>> -first ean13 6361324116001
>> -second ean13 4088885000328
>> -third ean13 0292430300229
>>
>>
>> if i read too fast with the barcode reader i get for example:
>>
>> 63613241160014088885000328 (the two first ean13 complete), i have fixed
>> this behaviour when the string % 13 == 0 but other times i get:
>>
>> 636132411600140888 and in the next row 5000328 so i dont know how to fix
>> this, if the computer running the program it is really fast (Core2 Duo
>> E6600 for example) it begins to be hard to see the error but all the
>> machine running the program are Pentium 4 < 2ghz or celeron and they are
>> very easy to make fail. How i can fix this?
>
> Yeah had the same issue, but i blame the scanner. usually keycodes dont
> get "lost".
> I am pretty sure that's not a Qt issue. Try subclassing QLineEdit and log the
> keyPressEvent. You'll see some losses too. blame the scanner manufactor of
> the people who HAVE to use polling for every shit they write no matter how
> often you tell them it's a broken concept.
> Note that some scanners can be configured to type slower. which makes working
> with them kinda anoying but thats fortunatly not my problem :P
>
>
>
>
--
[ signature omitted ]
Message 4 in thread
On Monday 14 April 2008 19:53:49 Linos wrote:
> but if i read at the same speed in a text editor or a console window i have
> not the problem, even the older clipper dos program running in dosemu
> doesnt have the problem, it should be a qt problem i think.
i can reproduce the problem using xev. especilly \r and \n get lost easily.
--
[ signature omitted ]
Message 5 in thread
I have tried with xev and i get in every read the correct Return keysym after the ean. I suppose this can be
other different problem.
Arvid Ephraim Picciani escribió:
> On Monday 14 April 2008 19:53:49 Linos wrote:
>> but if i read at the same speed in a text editor or a console window i have
>> not the problem, even the older clipper dos program running in dosemu
>> doesnt have the problem, it should be a qt problem i think.
>
> i can reproduce the problem using xev. especilly \r and \n get lost easily.
>
>
>
--
[ signature omitted ]
