Exclusive forum for HMG, a Free / Open Source xBase WIN32/64 Bits / GUI Development System
http://hmgforum.com/
Simple, is it easier this:Esgici wrote:Not at allkajko wrote:That implies that before main loop invocation (using ACTIVATE) I still can change all preactivate events on the window, eg. ON INIT.
Since you want change something before activation, what is meaning of make this out of definition?
Esgici wrote:As said before, somethings are assignable, and somethings are not
Correct, but whole point of this discussion is to determine why are they not and how we can overcame this lack in interface. This is, I believe, just oversight in interface implementation, nothing more, especially if HMG is aiming to introduce 'proper' event driven development (eg. for Windows, Gnome, ...) into harbour.Esgici wrote:"Some properties/events may or may not be defined in definition of windows" doesn't means "all of them may will be assign later"
Does that mean that &window.control.value := "something" will work ?Esgici wrote: Sorry, not correct. You can use macro substitution for name of window and can assign it at run time. for example :
(Notice & symbol before variable name)Code: Select all
PROC ABC( cCountry ) LOCAL cWinName := "frm" + cCountry + "Trans" DEFINE WINDOW &cWinName ...
As I explain in my example in previous post, I do not need to know is there a window or not, either way i need to create it again with, maybe, different parameters.Esgici wrote: Moreover we have very handy "is" functions; such as : IsWindowDefined(), IsWindowActive() ... We can use them for warrant using an unique window name; for example :
Code: Select all
PROC ABC( cCountry ) LOCAL cWinName := "frm" + cCountry + "Trans" IF !IsWindowDefined( cWinName ) DEFINE WINDOW &cWinName ... ...
Eh...it is never sufficient, if it is not assignable I want to know WHY ? It can be and it does not break anything, just gives me more freedom to express my self and write more productive code.Esgici wrote: Dear Kajko, I'm not a WinAPI expert, as a HMG user, it's sufficient for me knowing "if it's assignable or not"
, I was just trying to see if there is a 'legit' why of doing it.Yes, understood, but, my opinion is: you don't need this !kajko wrote:That implies that before main loop invocation (using ACTIVATE) I still can change all preactivate events on the window, eg. ON INIT.
Are you sure that we have only this two options ?kajko wrote:Simple, is it easier this:...
Code: Select all
DEFINE WINDOW wndKomit AT 0, 0 WIDTH w_width HEIGHT w_height ;
WINDOWTYPE CHILD ;
ON INIT OnInitKomit() ;
TITLE " Registar komitenata" ;
FONT "Bodoni" SIZE 9
...
PROC OnInitKomit()
if( <something> )
func1() }
else if( <something> )
func2()
else if( <something> )
func3()
etc....
RETU // OnInitKomit()
My opinion is : this isn't a lack.kajko wrote:... whole point of this discussion is to determine why are they not and how we can overcame this lack in interface.
As I said earlier, I'm not a Win32 expert, so I'm unable to understand what is 'proper event driven development'. In my opinion, HMG is most successful interface between WinAPI and us. And please consider that this opinion consisted after struggles with some other interfaces for dozen of years.kajko wrote:This is, I believe, just oversight in interface implementation, nothing more, especially if HMG is aiming to introduce 'proper' event driven development (eg. for Windows, Gnome, ...) into harbour.
Why "no way" ? As I said above, write your code, make your test; when satisfied send to forum. That's all.kajko wrote:... That is not possible at the moment as there is no way to replace win proc in HMG.
kajko wrote:Does that mean that &window.control.value := "something" will work ?
No ! Macro substitution is a Harbour feature, not HMG; and window.control.value is a HMG (semi OOP) notation, no Harbour.May be... But knowing the window is defined or not will protect you from "BOOM"kajko wrote:As I explain in my example in previous post, I do not need to know is there a window or not, either way i need to create it again with, maybe, different parameters.
I can't protest this point of view, moreover I have to appreciate. A programmer must be always investigative, even inquisitive. But have know their limits too. This is reason of my point of view by saying "it's sufficient for me knowing "if it's assignable or not".kajko wrote:... if it is not assignable I want to know WHY ? It can be and it does not break anything, just gives me more freedom to express my self and write more productive code.
Does that mean that in C++ there isn't "assignable" and "not assignable" concepts ?kajko wrote:I am sure Bjarne Stroustrup never imagined Boost when he was creating C++, but he was not building solid language on "if it's assignable or not".
) and many thinks come to me more quick and easy.Code: Select all
LOAD WINDOW TELA_PADRAO_HMG AS F_BAIXAR
// ON INIT TELA_ENTRADA() // esta linha não funciona
// F_BAIXAR.OnInit TELA_ENTRADA() // esta também não funciona.
// F_BAIXAR.OnInit := TELA_ENTRADA() // e esta também não funciona.
Code: Select all
DEFINE WINDOW wndKomit AT 0, 0 WIDTH w_width HEIGHT w_height ;
WINDOWTYPE MODAL ; //ON INIT OnInitKomit() ;
TITLE " Registar komitenata" ;
FONT "Bodoni" SIZE 9
...
OPEN WINDOW wndKomit
ON KEY F1 OF wndKomit ACTION ......
if( <something> )
func1() }
else if( <something> )
func2()
else if( <something> )
func3()
etc....
ACTIVATE WINDOW wndKomit
parece então, que terei que me adaptar ao padrão da LIB HMG...MICROVOLUTION wrote: ↑Sun Dec 27, 2020 11:23 am Mas, nem sempre a ON INIT TELA_ENTRADA será a mesma em todos os formulários herdados... Cada um tem a sua tela diferente.
Isso significa que terei que fazer um formulário novo para cada tela?