HMGforum.com

Hi All,

IMHO, we should follow these two STEPs:

1. I think it would be good time to create a convention rule when a new HMG version it's being installed.
   
   All of us we want to know where the HMG is installed, what folder it has been installed.
   
   At HMG instllations we would execute a procedure of creating and/or rewrite the HMGPATH variable of our enviroment, then this will be accessible at any place by just by invocating the simple variable %HMGPATH%.
   
   I know there are some user that prefer to use old HMG version...  (It's a mistery to know why, I really still do not understand that)
   But even for these users, this variable could be adjusted/rewritten to find the HMG path where ever be the HMG version.
   
   This enviroment variable HMGPATH would helps a lot for working with the last installed HMG version.
   And this is the best of best solution where now is a hole of undefined and important info in our work bench.
   
   But this HMGPATH variable needs to be created in our enviroment. As the same is done in other programming tools.
    
2. Reaching a consensus for HMGPATH variable creation for HMG, all HMG demands will be attended like as:
   • SAMPLES compiling
   • Compiling app by using a Build.bat in the path
   • Pre-Processor routines in the compiling which also needs a Harbour path of our HMG folder
   So we can elaborate a more definite Build.bat which we can call at any where by putting this file in a visible path for everybody.
   
   The best way to do it is be placed at: %windir%\System32 folder (by making at once with ADMIN rights of course).
   
   This works for all Windows versions and this other Build.bat file must contains as follows:

   Code: Select all

   @ECHO OFF
   CALL %HMGPATH%\Build.bat %1 %2 %3 %4

   Note in this propose, that we gonna pass to use %HMGPATH% variable what's previously created by HMG installations program or being set enviroment (create/modified) manually by user as related at this instructions for example.

Users can create this other Build.bat and placing at %windir%\System32 and manually writting a determinated and fixed path (for example: C:\hmg.3.4.4) but always when making upgrades, the user will also will have to change for the new path which would be a repetitive and unnecessary practice if we considered an environment variable for HMG thru %HMGPATH%. We need to think about it and approve it (Is my urge, needing and opinion).

Conventions is so good when we need a common needing. This %HMGPATH% variable it should happen before. Now it's at HMG users and administrators to approve.

To use Notepad++ is also a good idea but not workable for everybody which prefer another source editors... and for improving this idea of PLUGINS in NPP must be posted (IMO) in another topic as tutorial for Notepad++.

Hi Andres,

Thank you for sharing your experience, no doubt it is much wider than my.
I was afraid till now to try a different installation and simply followed the instructions for installing exclusively on C:.

Have a nice day,
Marin

Pablo César wrote: ↑Sat May 27, 2017 2:07 pm Hi All,

IMHO, we should follow these two STEPs:

1. I think it would be good time to create a convention rule when a new HMG version it's being installed.
   
   All of us we want to know where the HMG is installed, what folder it has been installed.
   
   At HMG instllations we would execute a procedure of creating and/or rewrite the HMGPATH variable of our enviroment, then this will be accessible at any place by just by invocating the simple variable %HMGPATH%.
   ..............

Hi, Pablo,

The idea is very good, in my opinion. Thank you.

How about answering these questions to make the "roadmap" to HMGPATH-variable a little bit more clear:
1. When (at what time) should be the HMGPATH-variable created - at installation time of the HMG version or after that?
2. How should that be done - automatically or manual?
3. What should the HMGPATH-variable contain at installation time? And after a new HMG-version is released?
4. What about the older versions (some of us use them, I am not)? How they could benefit from this HMGPATH?
5. Is it not enough to make the HMGPATH-variable simply at disposal to build.bat without putting the .bat-file in ..\\System32?
6. What should be changed in the building process for the demo-files? And for the user's applications?
7. What difficulties (if any) may arose in our day-today work when using this approach? Will it be convenient for the most of us?

I also would be glad to read different opinions in this matter from the members here.

Kind regards,
Marin

Hi Marin,

Thank you very much for your interest and for your highly constructive questions that help us to understand and making better to establish the convention of creating the HMGPATH environment variable proposed.

Marin wrote: ↑Sun May 28, 2017 6:48 am How about answering these questions to make the "roadmap" to HMGPATH-variable a little bit more clear

Yes for sure, Marin.
I will respond accordingly, but I wish for everybody feel free to be an openly discussed by users, if they understand that it is an important configuration to be made so that HMG is not let HMG without setting of installation, unknowing location in our work environment.
 

1. When (at what time) should be the HMGPATH-variable created - at installation time of the HMG version or after that?

HMG.?.?.?.Setup.exe could execute the variable creation as soon as the HMG installation is finished. So the installation application will know how to define "where" (in which folder) HMG was installed path.

 

2. How should that be done - automatically or manual?

I think the user can set this by leaving a checkbox available in case they want to set the HMGPATH variable on your computer.  

3. What should the HMGPATH-variable contain at installation time? And after a new HMG-version is released?

HMGPATH should contains the HMG folder (full-path) where was installed without inverse slash bar at end. Example: C:\hmg.3.4.4
And when it is released a new version that this same variable is on put the previous one. The last install always prevailing (unless the HMGPATH checkbox is unchecked).

 

4. What about the older versions (some of us use them, I am not)? How they could benefit from this HMGPATH?

For those who do not want to use the new version of HMG and want to use the old version they can continue the same way they used the old batch files for compilation. But if you want to use a Universal Build.bat, you can use this application to do the configuration without having any HMG installation or you can even create the environment variable manually (read this instructions).

The benefit of using HMGPATH would allow you to create a Universal Build.bat to always use the same version of HMG and wherever your project is.

 

5. Is it not enough to make the HMGPATH-variable simply at disposal to build.bat without putting the .bat-file in ..\\System32?

Yes, the indicated second step at my previous message explains that need to create an universal and new Build.bat and the best place to be stored is at %windir%\System32 folder ( C:\Windows\System32 ).

6. What should be changed in the building process for the demo-files? And for the user's applications?

I think all the Build.bat located at SAMPLES subfolders most of them the same, can be suppressed and replaced only by universal Build.bat.

Users will have an extra mode to compile their applications without to create any extra batch file.
We can compile our applications at Prompt Command by typing:

BUILD <program.prg>

or

BUILD <project.hbp>

 

7. What difficulties (if any) may arose in our day-today work when using this approach? Will it be convenient for the most of us?

I only see some difficulties when user make the HMG installation by the duly Setup.exe program and later the user rename the HMG folder...
If renames HMG folder, HMGPATH must also be re-attribed with the new folder name.

If HMG administrators would see the importance to have the variable environment HMGPATH as convention setup, would be very helpful but without any prejudice to users even been at older HMG version and for future.

 

Marin wrote:I also would be glad to read different opinions in this matter from the members here.

Me too, I think. Participation it is all the best, is essential for the community. We become rich with several, different opinions and ideas too...

 
Once again thank you Marin for the participation and interest in the subject and for all who have spent some time to read on this topic.

I thought it was setting HMG_folder in PATH to a good solution (I use it), but yours is much better

Thank you Dragan for your interest and support.