HMGforum.com

esgici wrote:Hi Apichit

apichit wrote:Help me please!
I copy source code to Timeout.prg but cannot compile it.

Please clarify cannot compile

Here compiled and run fine

Happy HMG

+1
I can also compile run sample

esgici wrote:Hi Apichit

apichit wrote:Help me please!
I copy source code to Timeout.prg but cannot compile it.

Please clarify cannot compile

Here compiled and run fine

Happy HMG

Hi esgici,

I compile with HMG.3.0.35 not pass and it show build log screen with blank Error list. No exe file created.
I need to use version 3.0.35 becase this version can use my local language.

Thank you

Apichit, this new MessageBoxTimeout function is made for UNICODE uses. There are some other ressources which you not find under 3.0.35 version.

apichit wrote:I need to use version 3.0.35 becase this version can use my local language.

But why are not using UNICODE version for your language too ? UNICODE supports all languages, it is how we use to read with one page of site in your browser. Totally transparent. If you finding out dificulties to adapt ANSI to UNICODE, I suggest you to start posting your doubts difficulties one by one. But UNICODE is the right way long for HMG, IMHO.

Pablo César wrote:Apichit, this new MessageBoxTimeout function is made for UNICODE uses. There are some other ressources which you not find under 3.0.35 version.

apichit wrote:I need to use version 3.0.35 becase this version can use my local language.

But why are not using UNICODE version for your language too ? UNICODE supports all languages, it is how we use to read with one page of site in your browser. Totally transparent. If you finding out dificulties to adapt ANSI to UNICODE, I suggest you to start posting your doubts difficulties one by one. But UNICODE is the right way long for HMG, IMHO.

+1

The problem is that DBF files don't support UNICODE

mol wrote:The problem is that DBF files don't support UNICODE

Hi Marek, could you tell us what kind of difficulties are you finding at DBF files in UNICODE mode ?

Reminding that we should use these following functions for strings treatments:

Support ANSI and UNICODE

IMHO, we have to decide how to work with the pre-existing dbf files. Continue to work in ANSI because DBF is already existing and has many ANSI accented caracterers in it or convert phisically all these accented caracterers into UNICODE ones. The ideal is not be mixed. If you wish to keep your databases in ANSI, so you will need to convert to ANSI in previous moment at saving to DBF. But also you will need to read and convert it when you make any treament of string. Because size of string in UNICODE and ANSI could it differes.

I am still believe that UNICODE is the best way to work.

Pablo César wrote:I am still believe that UNICODE is the best way to work.

+1

Viva HMG

Main problem, in my opinion, is with text fields. As you know, text field has declared size in one-byte characters. But, UNICODE strings can contain chars coded with two bytes. In the worst situation, you can save only a half of string in your database field.

mol wrote:Main problem, in my opinion, is with text fields. As you know, text field has declared size in one-byte characters.

Yes, but with these functions you can manipulate strings normally.

mol wrote:In the worst situation, you can save only a half of string in your database field.

Yes this could become a big problem if is not prevented with these string treatement functions. So you can avoid this kind of problems to convert UNICODE to ANSI when needs to save in DBF.

Maybe it's good for new projects, but requires a lot of work and testing in existing ones....
But, everything is to do... it's only a matter of time