Qtextedit, Qlineedit - encoding problem

1,075 views
Skip to first unread message

Zoran Sibinovic

unread,
Feb 19, 2014, 6:17:49 AM2/19/14
to qtcon...@googlegroups.com
Hi,

I have made

REQUEST HB_CODEPAGE_SR646
...
SET( _SET_CODEPAGE, "SR646" ) 
...

  oTextBox := QTextEdit( oDlg )
  oTextBox:setfont( QFont( "Courier New", 9 )) 
  oTextBox:Move( 685, 200 ) 
  oTextBox:Resize( 160,250 )
  oTextBox:setText( "Text @{}[]^"  )
  oTextBox:show()
...

now, while showing "Text @{}[]^", the text is displayed as it have to: "Text "ŽšćŠĆČ` , but if I want to continue to insert/input text directly, the special characters are not recognized anymore.

there is some way to make the input, in these objects, in the edit/line window, characters recognized/displayed according the selected codepage? 

Thanks for answers
Zoran



Zoran Sibinovic

unread,
Feb 21, 2014, 1:36:37 AM2/21/14
to qtcon...@googlegroups.com
Any suggestions?

Zoran

Luigi Ferraris

unread,
Feb 21, 2014, 4:52:04 AM2/21/14
to qtcon...@googlegroups.com
Il 21/02/2014 7.36, Zoran Sibinovic ha scritto:
Any suggestions?

Zoran

On Wednesday, February 19, 2014 12:17:49 PM UTC+1, Zoran Sibinovic wrote:
Hi,

I have made

REQUEST HB_CODEPAGE_SR646
...
SET( _SET_CODEPAGE, "SR646" ) 
...

  oTextBox := QTextEdit( oDlg )
  oTextBox:setfont( QFont( "Courier New", 9 )) 
  oTextBox:Move( 685, 200 ) 
  oTextBox:Resize( 160,250 )
  oTextBox:setText( "Text @{}[]^"  )
  oTextBox:show()
...

now, while showing "Text @{}[]^", the text is displayed as it have to: "Text "ŽšćŠĆČ` , but if I want to continue to insert/input text directly, the special characters are not recognized anymore.

Hi Zoran,
I'm not sure but can you try:
a) to use :setPlainText() instead :setText() and toPlainText() instead text()

b) on my program, in the INIT PROCEDURE, I'm using this:
hb_CdpSelect( "ITWIN" )
hb_SetTermCp( hb_cdpTerm() )
SET( SET_OSCODEPAGE, hb_CdpOs() )
Obviously, because I'm italian. Try the same with SR646.

In this scenario I can enter and print out (on a text file using Harbour/CLIPPER) right character like @[]{}ìèéòàùç§.

If this it doesn't works anymore, probably (but I'm not sure, only Pritpal can give you a right answer) is related with QtContribs internal. More specific about using "latin1" to translate input/output character: but remember I'M NOT SURE.

BR
Luigi Ferraris

Zoran Sibinovic

unread,
Feb 21, 2014, 6:29:12 AM2/21/14
to qtcon...@googlegroups.com, luigfe...@gmail.com
HI Luigi,

I have tried all of your suggestions, some before the post, some after, plaintext methods too, but without success.

You use ITWIN, I can use SRWIN or HRWIN and can work, but if I try to use a non-unicode codepage like SR646 the problem emerges.

I tried also in validator.prg regarding the @ say...get MEMOEDIT...
but even there is not works.

On the other hand, in the cell editing of a browse, that use Qlineedit, I can enter my characters, but dont know how Pritpal got it.

The interest thing is also, that the characters are displayed in the box correctly only if you use oTextBox:setText( "Text @{}[]^"  ) and dont want to change the text.

In the meantime I will wait for som Pritpals answer.

Thanks 
Zoran  

Luigi Ferraris

unread,
Feb 21, 2014, 8:58:13 AM2/21/14
to qtcon...@googlegroups.com
Il 21/02/2014 12.29, Zoran Sibinovic ha scritto:
HI Luigi,

I have tried all of your suggestions, some before the post, some after, plaintext methods too, but without success.

You use ITWIN, I can use SRWIN or HRWIN and can work, but if I try to use a non-unicode codepage like SR646 the problem emerges.

Hi Zoran.
I don't understand well your test sequence so what works and what won't works.

Anyway, if you like, can you build and run included file and see what happens?
As you will see, I'm using two objects: QLineEdit and QTextEdit.
Related with any one (same row) you can find two buttons: write (append) on a txt file the current object content, second button fill object with file content. Very simple.

As you will see, I'm setting ITWIN. It seems all works fine using keyboard and reading and writing file.

Can you play using SRWIN, HRWIN and SR646 ?

Take a look: there is a QLocale setting. I think you don't need to enable row with "//A". I have used to try your "language/country" on my Windows PC.
I can enter (copy/paste) characters like Ň (U+0147) Ő (U+0150) but they are not write into the file: can be a problem related with :text() method? or can be a problem related with hb_MemoWrit? or can be a problem related with my OS language?

BR
Luigi Ferraris

source.zip

Luigi Ferraris

unread,
Feb 21, 2014, 9:09:51 AM2/21/14
to qtcon...@googlegroups.com
Il 21/02/2014 14.58, Luigi Ferraris ha scritto:

Anyway, if you like, can you build and run included file and see what happens?
Hi Zoran, I'm sorry I do some errors code. This version is more correct.

BR
Luigi
source.zip

Zoran Sibinovic

unread,
Feb 24, 2014, 2:16:17 PM2/24/14
to qtcon...@googlegroups.com, luigfe...@gmail.com
Hi Luigi,

sorry for not answered till now.

I had tried today your code and it is ok, and it works for the examples I already mentioned, but not in case of non-unicode codepages.

As using SR646 is the same as you use ex. IT437 or IT850 (non-unicode) but not ITWIN (unicode).

In the mentime I found the reason of why my spec chars are not correctly displayed.

Since this happens using Qlineedit, Qtextedit. memoedit etc., but, not in ex. hbqtbrowse Qlineedit that is used for the cell editing (:editcell()).

I came to the conclusion: 

:editcell() had a control for every pressed sign/character that's analize the character, after which insert it or not in the text and refresh the screen text line.
In the other hand Qlineedit, Qtextedit. memoedit in their base use, had no control for individual characters so the text line is not refreshed.

In conclusion, the solution for the non-unicode or utf chatacters to be displayed correctly in Qlineedit. Qtextedit. memoedit, etc objects is to find a way to refresh them on every entered character. In that case the CP translation will be triggered.

Zoran

Luigi Ferraris

unread,
Feb 25, 2014, 9:18:13 AM2/25/14
to Zoran Sibinovic, qtcon...@googlegroups.com
Il 24/02/2014 20.16, Zoran Sibinovic ha scritto:
Hi Luigi,

sorry for not answered till now.
Don't worry :-)

Please remember that I'm not a guru, so I can write wrong info.... Take with care my opinions.


I had tried today your code and it is ok, and it works for the examples I already mentioned, but not in case of non-unicode codepages.
Qt (not QtContribs or HbQt) for its internal manage only unicode; when user set QLocale there are translation for input or output. But we are using a binding (HbQt).
When I use (ie) :setText( "luigi" )  or cVar := :text() is there something between my program and Qt? Yes, HbQt. in what way send or receive text to the real Qt object? As is or ?
I haven't idea .... sorry.

As using SR646 is the same as you use ex. IT437 or IT850 (non-unicode) but not ITWIN (unicode).
Harbour use UNICODE - Qt use UNICODE all works fine
Harbour don't use UNICODE - Qt doesn't know. Can you use (ie) hb_Translate( ...)? :setText ( hb_Translate( .... ) ) ?


In the mentime I found the reason of why my spec chars are not correctly displayed.

Since this happens using Qlineedit, Qtextedit. memoedit etc., but, not in ex. hbqtbrowse Qlineedit that is used for the cell editing (:editcell()).

I came to the conclusion: 

:editcell() had a control for every pressed sign/character that's analize the character, after which insert it or not in the text and refresh the screen text line.
In the other hand Qlineedit, Qtextedit. memoedit in their base use, had no control for individual characters so the text line is not refreshed.
HbQtBrowse do something, using hbQtWidgets, using HbQt to speak with Qt. The most simple way to check what happens is a simple QLineEdit and/or QTextEdit When you are able to set or to get right value this is the good way.
What codePage HbQtBrowse e/o HbQtWidgets (LineEdit) are still using? SR646, IT437 or ITWIN, SRWIN?


In conclusion, the solution for the non-unicode or utf chatacters to be displayed correctly in Qlineedit. Qtextedit. memoedit, etc objects is to find a way to refresh them on every entered character. In that case the CP translation will be triggered.
It's a very strange behaviour....anyway if it works!

BR
Luigi

Zoran Sibinovic

unread,
Feb 25, 2014, 4:34:20 PM2/25/14
to qtcon...@googlegroups.com, Zoran Sibinovic, luigfe...@gmail.com
HI luigi,

Qt (not QtContribs or HbQt) for its internal manage only unicode; when user set QLocale there are translation for input or output. But we are using a binding (HbQt).
When I use (ie) :setText( "luigi" )  or cVar := :text() is there something between my program and Qt? Yes, HbQt. in what way send or receive text to the real Qt object? As is or ?
I haven't idea .... sorry. 

When you send ex. oTextbox:setplaintext( ,,, ), the translation happens at the time of the execution of :setplaintext(). I suppose that the text is translated, as most of "   " values in the app code according the chosen CP, and placed in some memory buffer, then at the :show() or :exec() is displayed.

Instead of the above, when you directly enter the text in the box, there is no some intermediate step to make the translation.

 Harbour use UNICODE - Qt use UNICODE all works fine
 Harbour don't use UNICODE - Qt doesn't know. Can you use (ie) hb_Translate( ...)? :setText ( hb_Translate( .... ) ) ?\
 
As I said when you use some unicode cp while entering the text all is ok. The problem is not how to find some method for make the translation of the text to be staticly displayed, but the input action. As an example, imagine that there is no starting text, the box is executed with no text and you want to write some text in it. So there is no use of :seytext(), :setplaintext() or else.
What codePage HbQtBrowse e/o HbQtWidgets (LineEdit) are still using? SR646, IT437 or ITWIN, SRWIN?\
I dont use at this moment no locale, EN keyboard method and SR646 cp. 

I have tried this today:

....
   oTextBox:= QPlainTextEdit ( oDlg ) ; oTextBox:setfont( QFont( "Courier New", 9 )) ; oTextBox:Move( 685, 230 ) ; oTextBox:Resize( 170,260 )
   pep=0
  oTextBox:connect( "textChanged()", {||  pep:=IF(pep=1,0,1),IF(pep=0,oTextBox:setplainText(oTextBox:toplaintext())," ") } )
...
and happens that at the time I enter a character, the whole text is refreshed - stored in some buffer and than redisplayed according my selected CP.
The problem I faced is that the cursor is positioned at the beginning of the whole text/document, so more actions are required.

I tried also this;
  oTextBox:connect( "textChanged()", {||  oTextBox:setplainText(oTextBox:toplaintext())  } )
that is more logic, but every :setplainText() trigger the :connect, so the app after 2-3 sec stuck.

Thanks for answering
Zoran



Luigi Ferraris

unread,
Feb 26, 2014, 11:46:36 AM2/26/14
to qtcon...@googlegroups.com
Il 25/02/2014 22.34, Zoran Sibinovic ha scritto:
Thanks for answering
Zoran

Now it's my nightmare.....
Using a simple program (wihtout any harbour settings) here most rilevant lines:
WITH OBJECT oMyLineEdit := QLineEdit( oParent )
    :move( somewhere )
    :resize( something )
    :connect( "editingFinished()", { || udfTest( oMyLineEdit, oMyTextEdit ) } )
END WITH
WITH OBJECT oMyTextEdit:= QTextEdit( oParent )
    :move( somewhere )
    :resize( something )
END WITH

STATIC PROCEDURE udfTest( oMyLineEdit, oMyTextEdit )
    LOCAL cText :=  oMyLineEdit:text()
    oMyTextEdit:setPlainText( cText )
RETURN NIL

Using my italian keyboard (with ALT+0+decimalNumber) I try to enter some "Cyrillic" characters (ie) U+041F (dec.1055) , U+0453(dec.1107) , U+0431(dec.1073).
Where?
a) using WordPad and I can see the right characters
b) using this CLIPPER/QtContribs program... it doesn't works. I can only enter till U+00FF (dec. 255)

Using copy&past on LineEdit I can enter/copy a string with Cyrillic characters, but when editingFinished() is fired on, I see "??? ????" into QTextEdit object.
So, at the top of my program I add hb_CdpSelect( "SRWIN" ) and now I can see right characters. Then I change into hb_CdpSelect( "SR646" ) and I can't see right characters into QtextEdit.

A little question for you Zoran: why can't use "SRWIN" :-D :-D :-D

BR
Luigi

Zoran Sibinovic

unread,
Feb 26, 2014, 2:41:27 PM2/26/14
to qtcon...@googlegroups.com, luigfe...@gmail.com
Hi Luigi,

Nice question. :) 
In this moment I had no time to convert my apps to the unicode usage.
This was just a question in  case I missed something trivial to activate the correct display, but seems to be a bigger problem. 

Till now i dont had to, because my apps are completely independent of the locale settings or unicode cp-s. They just works and that's it.

The implementation of non-unicode cp-s have this purpose also
.
In the other hand Qt is not so flexible as it seems at first glance and it doesn't support the use of non-unicode cp-s, thats the reason why I had to wait for the use of hbqt, till Pritpal solves the cp-usage. 

He did in hbqtbrowse and in get/qget, but still remains some input classes that had no character controla regarding non-unicode cp-s.

I will study the code of your last post and try to find eventually some solution.

Another thing, non-unicode cp-s have only 255 chars in the table.

SRWIN as ITWIN is used in cooperation with the chosen language in the language bar of the windows taskar. 

Thanks
Zoran

Zoran Sibinovic

unread,
Feb 27, 2014, 5:33:57 AM2/27/14
to qtcon...@googlegroups.com, luigfe...@gmail.com
Hi,

found the solution for non-unicode cp-s to be correctly displayed in Qlineedit()

oTextLine:= Qlineedit ( oDlg ) ; oTextBox:setfont( QFont( "Courier New", 9 )) ; oTextBox:Move( 685, 230 ) 
oTextBox:setMaxLength( 50 )
oTextBox:setMaximumWidth( 48 * 5 )

oTextBox:connect( "textEdited(QString)", {|| oTextBox:settext(oTextBox:text()) } )   // this do the job
 
Tried with SR646 and works, during the entering, the text is buffered and retranslated before the re-display with a complete effect.

Now I will seach for Qtextedit, but it don't have the textEdited() that here is the only way to do the job.

Zoran



Francesco Perillo

unread,
Feb 27, 2014, 5:41:14 AM2/27/14
to qtcontribs

void QTextEdit::textChanged () [signal]

but ypu must check about recursive calling

You also have

void QTextEdit::keyPressEvent ( QKeyEvent * e ) [virtual protected]

but since it is virtual protected you need some c++

The solution you found Luigi already found in the past since I remember he used in his code... but it is an "hack".. harbour is used to do the conversion from UTF8 to codepage and then from codepage to UTF8 with :setText().








--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.
To post to this group, send email to qtcon...@googlegroups.com.
Visit this group at http://groups.google.com/group/qtcontribs.
For more options, visit https://groups.google.com/groups/opt_out.

Zoran Sibinovic

unread,
Feb 27, 2014, 6:15:16 AM2/27/14
to qtcon...@googlegroups.com
Hi Francesco,

The solution you found Luigi already found in the past since I remember he used in his code... but it is an "hack".. harbour is used to do the conversion from UTF8 to codepage and then from codepage to UTF8 with :setText().

I had not yet tried his code of the previous post and in the meantime made mine. I see it now. :)
Sure, that's a hack, but is acceptable when you have some deadline and not the time to make a comprehensive apps change to make it non a hack.

In the other hand, the problem appears also in validatr.prg in the

@ 9, 02, 12, 30  GET cNotes MEMOEDIT CONTROL oWnd:editNotes COLOR "N/rgb(255,255,230)" WHEN cText == "DEF" VALID "Harbour" $ cNotes 

when you enter in the edit mode.
So I suppose that Pritpal, when back, will take note of this to make it a non-hack. 
 
I've tried with all the qtextedit signals and tried to put some switches to avoid the recursivity, but the thing is not working. 
The last for today will be to try :keypressevent()

Thanks 
Zoran

Francesco Perillo

unread,
Feb 27, 2014, 6:54:30 AM2/27/14
to qtcontribs



On Thu, Feb 27, 2014 at 12:15 PM, Zoran Sibinovic 
Sure, that's a hack, but is acceptable when you have some deadline and not the time to make a comprehensive apps change to make it non a hack.

it is probably the quicker way to do it.
 

In the other hand, the problem appears also in validatr.prg in the

@ 9, 02, 12, 30  GET cNotes MEMOEDIT CONTROL oWnd:editNotes COLOR "N/rgb(255,255,230)" WHEN cText == "DEF" VALID "Harbour" $ cNotes 

First of all it seems that for MEMOEDIT QPlainTextEdit is used and not QTextEdit.


when you enter in the edit mode.
So I suppose that Pritpal, when back, will take note of this to make it a non-hack. 

Yes, it can be done, continue reading
 
 
I've tried with all the qtextedit signals and tried to put some switches to avoid the recursivity, but the thing is not working. 
The last for today will be to try :keypressevent()

keyPressEvent can't be used as is, you should subclass...

But if you read getsys.prg in hbqtwidgets dir you will see that something is already done...
::oEdit:connect( QEvent_KeyPress, {|oKeyEvent  | ::execKeyPress( oKeyEvent )   } )
all keypresses are handled by Pritpal code in ::execKeyPress method.

I think you may "insert yourself" in that code and change the value of the keypress... it always involving harbour to get the utf8 value and discard the keypress if it is not valid in your codepage...

Zoran Sibinovic

unread,
Feb 27, 2014, 7:11:53 AM2/27/14
to qtcon...@googlegroups.com
Thanks,

I will consider it.

Zoran

Luigi Ferraris

unread,
Feb 27, 2014, 9:54:01 AM2/27/14
to qtcon...@googlegroups.com
Il 27/02/2014 11.41, Francesco Perillo ha scritto:
> The solution you found Luigi already found in the past since I
> remember he used in his code... but it is an "hack".. harbour is used
> to do the conversion from UTF8 to codepage and then from codepage to
> UTF8 with :setText().
Hi friends,
I write a very simple C++ program using QtCreator: a QmainWindow and a
QLineEdit.
Using keyboard the behaviour is the same: only till 255 code can be used
to enter characters. ie ALT+126, ALT+65 or ALT+0+255. If I use a decimal
code greater than 255 nothing happen. So, I think this is the normal Qt
behaviour and QtContribs works fine.

I observed that using ALT+254: C++ program works fine while
CLIPPER+QtContribs crash with hb_out.log

On the other hand, while googling I found some post related with this
problem...

BR
Luigi

Luigi Ferraris

unread,
Feb 27, 2014, 1:52:51 PM2/27/14
to qtcon...@googlegroups.com
Il 27/02/2014 13.11, Zoran Sibinovic ha scritto:
> Thanks,
>
> I will consider it.
>
> Zoran
Hi Zoran, I think there are only two options:
a) intercepting keyboard events and translate character...but as
Francesco writes...probably there are problems related with protected
functions for some/many objects.
b) setting a different keyboard layout. If I remember well, you are
using a English keyboard layout but you want enter Serbian (cyryllic)
characters. Can you play with a different (cyrillic) keyboard and check
what happens?

Related with last you can search on internet "qt changing keyboard
layout". You will find a ton of questions :-) and very few good answers
for c++ programmers.

BR
Luigi

Zoran Sibinovic

unread,
Feb 27, 2014, 2:12:21 PM2/27/14
to qtcon...@googlegroups.com, luigfe...@gmail.com
Hi Luigi,

You are right about the english keyboard, but SR646 regards Latin characters, so the characters to enter are latin with about 10 special accented characters as you have in italian ex. "Marco è più bello di...".

So if you use for example IT850 instead of  ITWIN, you will faced the same problem.

As I said to Francesco I currently have no time to make big app changes to use HRWIN (serbian latin ) or SRWIN (cyrillic) that will do the job.

To be frank I did not expected this problem since Pritpal had done a great job with the qget and the browse sistem to accept the use of all cp-s. 
Seems this is a remained tail in the enterprise of make HBQT perfectly compatible with, in this case, all the harbour cp-s and their usages.  

Just wait Pritpals back to assault him with the request.  :)

Zoran
Reply all
Reply to author
Forward
0 new messages