HMGforum.com

Hi, I have a code like this:

DEFINE WINDOW wndKomit AT 0, 0 WIDTH w_width HEIGHT w_height ;
WINDOWTYPE CHILD ;
TITLE " Registar komitenata" ;
FONT "Bodoni" SIZE 9 ;
ON INIT EnableFields(.F.) ;
ON RELEASE close_dbf(dblista)

Problem i have is that regarding current path in the program, ON INIT and ON RELEASE functions are dynamic. My question is:

Is there any way to create window WITHOUT ON INIT, ON RELEASE and assign it latter, like this:

DEFINE WINDOW wndKomit AT 0, 0 WIDTH w_width HEIGHT w_height ;
WINDOWTYPE CHILD ;
TITLE " Registar komitenata" ;
FONT "Bodoni" SIZE 9

wndKomit.OnInit := {|| EnableFields(.F.) }
wndKomit.OnRelease := {|| close_dbf(dblista) }

Considering it is a code block anyway in the first declaration, i do not see why not, but i can not find obvious way to do it.
Anyone ?

Thanks,
Kajko

you can use logical variable which is initiatiated as true, eg. lInitTime, and later, set lInitTime to .f.

I am sorry, but I have no idea what you are talking about. Can you explain please ?

you can use such a construction: Marek
...

Thanks all, but,
I need completely different functions called on different paths of the program.
Are you telling me there is no way to assign new functions to window after creation ? If that is true, I think then it is very strange interface design decision and implementation. As far as I can see from 'i_window.ch' it is simple code block, and as such should have corresponding window property. But that's just me...
Anyway, I can use direct call to '_DefineWindow' function and sacrifice my program compatibility (probably) with next versions of HMG.
Thanks to all who took time to answer.

Kajko

If I understood you, I think, you can do it in this way:

Hi Kajko

Before all, please don't panic and don't worry; you are between friends here

I'm afraid that it's difficult help you, without understanding your intention with "different paths"

If I'm correctly understanding, you want make an assignment to ON INIT event at out of design time.

ON INIT is an EVENT, not a property. Even all properties doesn't assignable out of design time. If we haven't ability to make an assignment to anything out of its definition, this means that simply this assignment available only at definition, that is all.

In other hand, ON INIT means "when a Window is initialized", and this occurs after activation of form (with ACTIVATE command) and before main event loop begin. In fact, main event loop begin with ACTIVATE command and ON INIT is squeezed in that very short interval. When ( which time) making your assignment you want ?

kajko wrote:... I think then it is very strange interface design decision and implementation.

Yes, it is

Because HMG is very robust, powerful, simple and intuitive; moreover extremely stable and reliable

Again, welcome aboard and good journey

Regards

--

Esgici

Yes, you understand correctly and I believe that I understand correctly:

some where in PRG:
...
DEFINE WINDOW wndKomit AT 0, 0 WIDTH w_width HEIGHT w_height ;
WINDOWTYPE CHILD ;
TITLE " Registar komitenata" ;
FONT "Bodoni" SIZE 9

is DESIGN TIME and all controls I put after that command and before ACTIVATE command is, from program execution perspective, DESIGN TIME of the window. That implies that before main loop invocation (using ACTIVATE) I still can change all preactivate events on the window, eg. ON INIT.

Even post loop event should be allowed to be changed/assigned during message loop of the window, as it will be executed/invoked after msg loop is finished and window is about to be closed/freed, eg. ON RELEASE.

Considering program execution path, some controls may or may not be included in window context creation (design time ) so why not allow dynamic change of window events handler (assuming programmer/developer knows/understands what and when) ?

Kajko

...and more on the side of constructive thinking...
Because name of the window is 'translated' from _NAME_ to "_NAME_" using precompiler, makes it unusable for window/form reuse AT THE SAME TIME, eg. one can not create unique window name at the time of program execution, window name must be defined at the time of code writing.

I will try to explain using example:

Phone/address book, big corporate company, lots of customers from around the world:
User got new order from Spain and France, it is first order from those countries but user does not know that.
User starts to input order into system, he got to the field to enter customer, customer is not there (first order from him), without closing entry form he selects from menu to work with registry of customers, open form, enter customer data, and before closing it, decide to check second customer just in case. He try to open registry of customers again ... and BOOM window already defined and app crash.

This is just a simple example, situation can be avoided by forcing user to close previous windows (making them MODAL for example) but then application lose flexibility and user is reluctant to use it (entering order for past 15-20 min and have to scrap everything because one of the items is not registered in the database, close window, open items registry, register item, close, go back inputing everything again hoping everything else is defined).

Kajko

Hi Kajko

kajko wrote:Yes, you understand correctly and I believe that I understand correctly:

I'm not sure

kajko wrote:...is DESIGN TIME and all controls I put after that command and before ACTIVATE command is, from program execution perspective, DESIGN TIME of the window.

Correct.

kajko wrote:That implies that before main loop invocation (using ACTIVATE) I still can change all preactivate events on the window, eg. ON INIT.

Not at all

Since you want change something before activation, what is meaning of make this out of definition?

kajko wrote:Even post loop event should be allowed to be changed/assigned during message loop of the window...

As said before, somethings are assignable, and somethings are not

kajko wrote:Considering program execution path, some controls may or may not be included in window context creation (design time)

Correct.

kajko wrote:so why not allow dynamic change of window events handler (assuming programmer/developer knows/understands what and when) ?

"Some properties/events may or may not be defined in definition of windows" doesn't means "all of them may will be assign later" Again, somethings are assignable, and somethings are not

kajko wrote:... eg. one can not create unique window name at the time of program execution, window name must be defined at the time of code writing.

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)

Moreover we have very handy "is" functions; such as : IsWindowDefined(), IsWindowActive() ... We can use them for warrant using an unique window name; for example :
Dear Kajko, I'm not a WinAPI expert, as a HMG user, it's sufficient for me knowing "if it's assignable or not"

It's very enjoying discussing with you; with hope of continue,

Regards

--

Esgici