FMG Editor

[Pablo César]

Current HMG_PATH

As I explained, now in these routines with hb_compileFromBuf I will need to know where the includes HMG files are located and this must be done at runtime app execution. I understand that each user installs the folder name in preference to them, it's time for the HMG installation.

Shall will see the possibility to implement in HMG the PATH of the current HMG library ?

There is another case which is needing to know the current HMG version, thru HMGVersion() the function returns from the constant _HMG_VERSION_NUMBER_ in MiniGUI.ch file.

Here is part of code involved in this question:

pPP := __PP_INIT("C:\HMG.3.2\INCLUDE","i_window.ch") // Here we can regulize with function extracting HMG path

The problem is this file must be open and seems we need to put the path as first parameter. So in other words: every body (including common user) they must have this file in current or any where.

Dear Claudio, I need your help to solve this problem:

If we further use of this resources as part of HMG library, we will have to think how to make available these files:

• i_window.ch
  i_altsyntax.ch

Do you think we could incorporate in .rc file or there is another way to access it the already in memory of actual system ?

[Pablo César]

Dear Claudio, I need your help to solve this problem:

If we further use of this resources as part of HMG library, we will have to think how to make available these files:

• i_window.ch
  i_altsyntax.ch

Do you think we could incorporate in .rc file or there is another way to access it the already in memory of actual system ?

I reduced both files utilized or probably more by including only Minigui.ch. This file includes all other necessary for HMG. But still persist the BIG problem to know Current HMG_PATH.

I have made one routine to detect the last HMG version and its installed folder. I think I will utilize that.

So, I prepare another example, which I believe is working fo all components and you can test it with your fmg files:

Code: Select all

/*
  Demo2.prg for loading FMG file as Form_2 and CHILD WindowType
  Author: Pablo César Arrascaeta
  Date: Abril 24th, 2014
*/

#include <hmg.ch>

REQUEST __PP_STDRULES

Function Main(cFmg)
Local cFileFmg:=""

If cFmg=Nil
   cFileFmg := Getfile ( { {'Forms','*.fmg'} } , 'Open form' )
   If Empty(cFileFmg)
      MsgStop("FMG file is necessary !")
   Endif
Else
   If !(".FMG" $ HMG_Upper(cFmg))
      cFmg := cFmg + ".fmg"
   Endif
   If File(cFmg)
      cFileFmg := cFmg
   Else
      MsgStop("File "+cFmg+", not found !")
   Endif
Endif
If Empty(cFileFmg)
   Return Nil
Endif

DEFINE WINDOW Form_1 AT 219 , 253 WIDTH 678 HEIGHT 426 ;
	TITLE "Form_1" MAIN

END WINDOW

DECLARE WINDOW Form_2

Exe_Fmg(cFileFmg)

CENTER WINDOW Form_1
CENTER WINDOW Form_2
ACTIVATE WINDOW Form_1, Form_2
Return Nil

Function Exe_Fmg(cFileFmg)
Local cCommand, pPP, cResult, cWinType, aLines, Code_Fmg:="", i

cCommand := hb_MemoRead( cFileFmg )
cCommand:=StrTran(cCommand,"TEMPLATE","Form_2")
If ("MAIN" $ HMG_Upper(cCommand))
   cCommand:=StrTran(cCommand,"MAIN","CHILD")
   cCommand:=StrTran(cCommand,"Main","CHILD")
   cCommand:=StrTran(cCommand,"main","CHILD")
Endif
If !("CHILD" $ HMG_Upper(cCommand))
   aLines := hb_ATokens( cCommand , CRLF )
   nLen := Len(aLines)
   For i=1 To nLen
       Lin_Fmg := RTrim(aLines[i])
	   If "DEFINE WINDOW" $ HMG_Upper(aLines[i])
	      aLines[i] := aLines[i] + " CHILD"
	   Endif
	   Code_Fmg := Code_Fmg + aLines[i] + CRLF
   Next
   cCommand := Code_Fmg
Endif

pPP := __PP_INIT("C:\HMG.3.2\INCLUDE","Minigui.ch") // Englobes: i_window.ch and i_altsyntax.ch HMG files
cResult:=__PP_Process( pPP, cCommand )
If !Empty(cResult)
   Exe_Function(cResult)
Endif
pPP := Nil
Return Nil

Function Exe_Function(cCommand)
Local cPrg := "Function Run_PP()" + CRLF + ;
              cCommand + CRLF + ;
              "Return Nil"

HRBCODE := hb_compileFromBuf( cPrg, "harbour", "-mt", "-o",  "-i" + "C:\HMG.3.2")
HANDLE_HRB := hb_HrbLoad( HRBCODE )
hb_HrbDo( HANDLE_HRB )
hb_HrbUnload( HANDLE_HRB )
Return Nil

It was easier than I thought. I wish to receive your comments please.

This code could be build with 3.2 version and your HMG must be installed at: C:\HMG.3.2 untill we find the best solution.

There is also necesary to make an error routine in order to show the line and avoid attemping app crash. Because, if not founding a function in ACTION components or there is any incomplete fields for Grid for example, will be an runtime error.

[Rathinagiri]

WINDOW LOAD FROM <fmgname> AS <alias_form_name> WINDOWTYPE <Main/Child/..>

Surely we can make this Pablo. Wish you experiment more and come with success.

[Javier Tovar]

Excelente Pablo César funciona con varios *.FMG que tengo a la mano!

Saludos

[mol]

But, what abot ON Init, On Get Focus event functions?
How to turn it off while activating window loaded in this way?

[Pablo César]

WINDOW LOAD FROM <fmgname> AS <alias_form_name> WINDOWTYPE <Main/Child/..>

Surely we can make this Pablo. Wish you experiment more and come with success.

Thank you Rathi, good to know that you liked the idea and approved.

But I am not sure to be beneficiala to HMG system due this question, by following reasons:

- Security in the systems to be developed with this option. Since someone could change the fmg and with some programming knowledge and knowing the system, could view fields that should not appear and without any rebuilding... While each developer can evaluate this risk in advance and let this option to be available or not.

- The Read_Fmg() function need to re-interpret commands thru HMG includes files and be recompiled by the Harbour in the buffer. So for the smooth functioning, we must provide the Harbour and includes files. And without such conditions provide the loading of the form, would be compromised. Although we would have to go deeper on this issue, to learn how we can simplify what are exactly the files that the system needs and perhaps make them available in a sub-folder of the current folder.

Anyway, I will advance the development of FMG Editor, as this seems to be the ideal most likely to give everything the right way.

---

Excelente Pablo César funciona con varios *.FMG que tengo a la mano!

Gracias Javier por confirmar el funcionamiento con tus fmg. Eso indica que tus archivos fmg no posuen inconsistencias.

---

But, what abot ON Init, On Get Focus event functions?
How to turn it off while activating window loaded in this way?

Yes Marek good remember, this It will be the next step. Very easy. I will turn off all actions and events and will be converted into STRINGs not executable, only by macro processor (but this will be not changed at original fmg file).

To all, thank you for the interest and help we are paying me. Hopefully soon able to provide the FMG Editor that can contribute either with icons with improved size of the buttons, put images on buttons, see other options and make them available.

And of course continue with the intended points:

1. To open any fmg file.
2. To add ContextMenu for all components automactically
3. To add to ContextMenu, following itens:
   a. Move
   b. Resize
   c. Align
   d. Properties
   c. Select/Unselect
4. Make select and multi-select by clicking of mouse
5. ComboBox with all itens for seletable item
6. To add grids (something like this) with selectable scale
7. To display selected component position at form x,y
8. Preview of fmg

Marek, probably it will be not necessary to create a ContextMenu for each components.
Instead, make an event control function for all components. That is, it would be a generic, because the options might be to basically the same items and we can also restrict each option, according to conditions of some elements. I mean, not all components have the same propierties, some are missing.

What do you think ? Would make you a demo with various components and see how it would be with generic ContextMenu ?

[Rathinagiri]

Do you plan to include this .fmg file to be sent along with exe? It should not be.

[Pablo César]

Do you plan to include this .fmg file to be sent along with exe? It should not be.

Yes, must be include in this case. This is one serious question.

Before to releasing this resource (WINDOW LOAD FROM <fmgname>...) into HMG lib, we need to evaluate if this for own risk to used it. Because all developers can use it to load the fmg from the file. Then fmgs files, should go together with applications made by them. Otherwise, forms using this mode, will not be loaded.

I just having another idea. We also could decide for scripting fmg files only in that condition, ie compulsory or not, leaving this decision to the programmer (also is a free choice).

We might also consider how to include contents of the fmg file into the .rc file too.

We shall discuss this question, because is important before to be released into HMG lib.

I really like the idea of having the forms created and then you can reuse it. It helps a lot to maintenance, especially when the customer requires changes. Then the fmg files are of great value in the manufacture and maintenance of screens.

I also like the idea of fmg files are being in text mode, it make easier for reusability although it should be handled with caution and common sense.

What could it be your suggestions, Rathi ?

[Rathinagiri]

Pablo, we can use entirely a different concept here.

XML.

Yes, XML is very easy to maintain, even by our customers also. Reading and writing xml is easy.

For example,

Code: Select all

<window>
   <name>main</name>
   <row>30</row>
   <col>30</col>
   <width>400</width>
   <height>300</height>
 </window>

We have to decide what are all the things we can share with user and what are all to be retained with the developer. (For example, as Marek stated we can't expose the OnGotfocus function name to user.

In my personal opinion, we need not share fmg file with the users. It should be forming part of our compilable code and should be incorporated in exe file.

[Pablo César]

Pablo, we can use entirely a different concept here.

Yes, this a very important issue to be approached.

We have to decide what are all the things we can share with user and what are all to be retained with the developer.

Yes this is one good question. But you do not think the developer would decide this ? I am referring when developper makes a simple app which considere not important to be exposed with screen made on the fly. Common user, does not have knowledge to make programms and also they are unknown with the internal structure of files and what it is used for.

In other words is quite the same idea to think that delivering DBFs to the client is a big risk. And in somewhat, yes it is a risk, IMHO.

For example, as Marek stated we can't expose the OnGotfocus function name to user.

I believe there is a confusion around this new approach of opening fmg files. Let see what the proposal is:

- To take fmg file and be loaded by WINDOW LOAD FROM <fmgname>...
- Is by own risk of developper to assume to load fmg file on runtime, not as usually does: assambled in the exe file.
- I never said to release forms editions to the common users. I just creating a FMG Editor for developpers. This is just a complementary tool for us we make programs, that´s so.

Common user can not see any events happing by the new way that I am suggesting.
As I previously said, we can script the fmg file and the problem will be finished.
No body, except the developper can change the input screen on scripted fmg.
Your suggestion to use xml in place of fmg (for that loading window case) also must be scripted the xml file too for security reasons only.

In my personal opinion, we need not share fmg file with the users. It should be forming part of our compilable code and should be incorporated in exe file.

Yes, I agree with you. As I said at begining, this resources could it be good or not... probably this do not need to be released as part of our lib. Better to know that it is possible to load, it is possible to read, its is possible to excute on runtime and must be considered the ethical and security reasons, already mentioned.

But please, feel you free to include this new concept of loading forms into our lib or not. The important here is to learn and make better tools for developping systems.

P.S. Rathi, I think we should split this topic treating this matter in another new topic. Just to not mix subjects. What do you think ?