HMG 3.4.3

[huiyi_ch]

After a preliminary test, the program(unicode and ANSI mode) for the INI file in Chinese characters, set and get all normal, the problem have been solved perfectly.

Thank you Mr. Yi for reporting your results and happy to know is satisfactory. The problem was not only for chinese characters, there are other languages with special characters that it could have been affected at time ago... now is solved, I guess.

...question of the function getstatupfolder() viewtopic.php?f=43&t=4738&start=80, please pay attention a bit! If the next version the question will be solved , it would be great.

Now I am understanding what you was saying... You wrote chinese language mixed with codes and is very often to ignore other languages when we do not understanding... (sorry but it's the true, I often see this in Spanish section). Also your codes are not exemplified very well and you not so clear in your objective. Because we do not know what you presented it is your problem or if you are only presenting your opinion...

That is why when we do not master the English language, it is good to post in both languages (as you did in your last message posted).
Thus the user can translate himself from the native language at any other conciliating language (for example). Because sometimes google translator makes translation errors.

Regarding your suggestion (how to remove last unnecessary backslash), I do not seem to be the ideal solution. Since HMG works with UNICODE as default and these functions you have indicated are not for handling strings in UNICODE mode. And certainly folder names sometimes contain local language characters, so it should be handled in UNICODE mode not in ANSI.

My suggestion is to replace the GetStartUpFolder() function with the proper Harbour function use, like this:

Code: Select all

Function GetStartUpFolder()         // by Pablo on November, 2016 - To remove last unnecessary backslash
Return cFilePath(hb_ProgName())

Claudio, could this solution be adopted in HMG core ? Or replace GetStartUpFolder() function (eliminating at h_controlmisc.prg) with:

#xtranslate GetStartUpFolder() =>cFilePath(hb_ProgName())

At ch file, as you prefer.

Remarks: Must be tested in ANSI mode to be sure all working properly for both modes. Please Mr. Yi: test it and revert to us.

Hi Hui, Claudio and friends,

For UNICODE works perfectly, the question is for ANSI mode. Of course and rebuild HMG in ANSI and make tests.

I have tested with this code example and with this changing to see results:

Code: Select all

#include <hmg.ch>

REQUEST HB_CODEPAGE_GBK

Function Main
hb_CdPSelect("GBK")
MSGDEBUG(MyGetStartUpFolder())
Return

Function MyGetStartUpFolder()    // by Pablo on November, 2016 - To remove last unnecessary backslash
LOCAL cStartUpFolder

If HMG_IsCurrentCodePageUnicode()
   cStartUpFolder := cFilePath(hb_ProgName())
Else
   MsgInfo("In ANSI")
   cStartUpFolder := cFilePath(GetProgramFileName())
Endif

If hb_ULeft(cStartUpFolder,1) = "\"
   cStartUpFolder := hb_ULeft( cStartUpFolder, HMG_Len( cStartUpFolder ) - 1 )
Endif
Return cStartUpFolder

I have created a subfolder called "返回结果正确" and run it my demo and the bad result is this:

Screen17.png
I tried Claudio to modificate GETPROGRAMFILENAME and GETMODULEFILENAME replacing GetModuleFileName by GetModuleFileNameA in trying to pass working these C functions only for ANSI. But it didn't work.

Screen18.pngThis changing to GetModuleFileNameA, it doesn't compile in UNICODE.

How it could could for ANSI (which is the main problem) for get right folder name ?

Sorry Mr. Hui. My knowledge is very very limited (quite nothing) in C. So it's not more in my hands, I guess.

对于这些问题，我的解决办法是修改文件h_controlmisc.prg中的函数 GETSTARTUPFOLDER () 与cFilePath（) ,修改后重新编译，经过测试（UNICODE和ANSI模式),函数GetStartUpFolder()和cFilePath（) 返回结果正确。不知这样修改是否妥当？修改后的代码如下：

On these problems ,My solution is to modify the functions GETSTARTUPFOLDER () and cFilePath () in the file h_controlmisc.prg, modified and recompile, and test (UNICODE and ANSI mode). The functions GetStartUpFolder () and cFilePath () returns the results were correct. I wonder if this change is appropriate? The revised code is as follows:

Code: Select all

Function cFilePath( cFileMask )
Local cDir
// hb_FNameSplit( cFileMask, @cDir, @cName, @cExt, @cDrive )
   hb_FNameSplit( cFileMask, @cDir, NIL,    NIL,   NIL     )
// Return HB_ULEFT ( cDir, HMG_LEN( cDir ) - 1 )
Return LEFT ( cDir, LEN( cDir ) - 1 )

Function GetStartUpFolder()
Local StartUpFolder := GetProgramFileName()
// Return HB_ULEFT ( StartUpFolder , HB_UTF8RAT ( '\' , StartUpFolder ) - 1 )
Return LEFT ( StartUpFolder , RAT ( '\' , StartUpFolder ) - 1 )

test code is as follows:

Code: Select all

 
#include <hmg.ch>
request hb_codepage_gbk
Function Main
    local path:=""
	
	path:=cFilePath(hb_ProgName())
                msginfo(path,"cFilePath()")
	msginfo(getcurrentfolder(),"getcurrentfolder()")
	msginfo(getStartupfolder(),"getStartupfolder()")
	
	hb_CdPSelect("GBK")  //with chinese os, on ANSI mode  must use hb_CdPSelect("GBK") ,else display "?????"
	path:=cFilePath(hb_ProgName())
                msginfo(path,"cFilePath()")
	msginfo(getcurrentfolder(),"getcurrentfolder()")
	msginfo(getStartupfolder(),"getStartupfolder()")
Return

regards to all

[Pablo César]

Hi Pablo

ANSI versions of these functions:

Code: Select all

HB_FUNC( GETPROGRAMFILENAMEA )
{
   CHAR Buffer [MAX_PATH + 1];
   GetModuleFileNameA(GetModuleHandle(NULL), Buffer, MAX_PATH);
   hb_retc(Buffer);
}

HB_FUNC( GETMODULEFILENAMEA )
{
   CHAR Buffer [MAX_PATH + 1];
   HMODULE hModule = HB_ISNIL(1) ? GetModuleHandle(NULL) : (HMODULE) HMG_parnl(1);
   GetModuleFileNameA(hModule, Buffer, MAX_PATH);
   hb_retc(Buffer);
}

Thank you KDJ. I will test it by rebuilding our lib in UNIDCODE and ANSI and make test. I will revert. Thank you for your corrections.

---

Mr. Hui, your porposal of changing HB_ULEFT for LEFT, elimenating hb_FNameSplit, changing HB_UTF8RAT for RAT it is not gonna works (IMO - In My Opinion). Because hb_U familiy its works with both case UNICODE and ANSI but it's not happend with LEFT, RAT... to UNICODE.

Have you tested what you have porposed ? I mean, have you hange function and rebuild in both (UNICODE/ANSI) ??

Added later:
Let me make some tests and I will revert to you...
I think you are right partially. Let me find final understanding...

[Pablo César]

To Mr. KDJ, (by the way.. could tell me what your name is, please?)

Your code passed well on the compiling process, but it did not work...
In fact I got tired of trying in various ways in C without a positive result ... so I decided to use the functions in Harbour and some result I got successfully or maybe partially with success. So I'm putting aside the C functions for both UNICODE and ANSI to get the name of the application folder being run.

In Harbour, function like as: hb_ProgName() and hb_DirBase() works properly in both modes.

---

To Mr. Hui,

As I said in my added later text at final of message in my previous one.
There is problem at removing last backslash of cStartUpFolder path but not in cFilePath function. This is working perfectly in both modes (UNICODE and ANSI). So, by changing in cFilePath function as have you recommend, it would causes many problems at UNICODE mode.
I have tested and I am sure of that.

However, you are right regarding strings manipulation at removing last backslash procedure, when is in ANSI mode.

I have changed GetStartUpFolder() function to differentiate when is UNICODE and when is in ANSI and this it works good.
I do not know, If I have correctly adopted the use of the HMG_IsCurrentCodePageUnicode() function (probably Mr. Claudio Soto could gives us his tip). Because this works properly whe PRG when is saved in UNICODE or saved as ANSI to get the right differentiation.
Probably is the mode of HMG is had been builded what is really be interesting. But to get this information?

Please be kind to test this new code example:

test.rar

Executable and source files

(2.57 MiB) Downloaded 263 times

This is the most I came close to getting the folder name with special characters for both ANSI and UNICODE.

But it needs to be tested because it is coming to me with this result:

Screen19.png (7.91 KiB) Viewed 7368 times

In UNICODE mode, even in the Chinese language, it brings me the special characters correctly, as my example proofs that:

Screen20.png (17.67 KiB) Viewed 7344 times

To test in UNICODE mode, please remove or let it as comment lines where is: REQUEST HB_CODEPAGE_GBK and hb_CdPSelect("GBK") otherwise HMG will considered as always in ANSI.

Very important for compilling test to be considered the test.hbc file. There is a special command to update executable file also located in the subfolder called "返回结果正确" during the compiling process. This is just for testing proposes. This folder is also important not be deleted. You can make position in it and click on the executable file to test from this subfolder.

Waiting your report for your testing and your suggestion to solve it.

[Pablo César]

I do not know, If I have correctly adopted the use of the HMG_IsCurrentCodePageUnicode() function (probably Mr. Claudio Soto could gives us his tip). Because this works properly whe PRG when is saved in UNICODE or saved as ANSI to get the right differentiation.
Probably is the mode of HMG is had been builded what is really be interesting. But to get this information?

I know now how to do it.

The right thing is to replace HMG_IsCurrentCodePageUnicode by HMG_SupportUnicode()

[KDJ]

To Mr. KDJ, (by the way.. could tell me what your name is, please?)

My name is difficult to pronounce in a language other than Polish, so I use the initials.

Best regards
Krzysztof aka KDJ

[Pablo César]

Hi Krzysztof,

The polish sound of your name it's like Kreeshhtof, means Christopher. Nice name.

Polacy są bardzo piękne i inteligentne.

W przyszłości chciałabym wyjechać do Polski.

OMG, the language seems to be very very difficult...

[serge_girard]

Krzysztof == Christof .OR. Krzysztof LIKE Chris !

[mol]

You should write

Polki są bardzo piękne i inteligentne.

Rather.
Hahaha

[Pablo César]

You should write

Polki Rather.
Hahaha

Damn translator

[mol]

And it's quite enough reason to go to Poland!