Koda

Welcome to Koda bug tracker!

At the moment you can post bugreports or suggestions anonymously. But registered users have some benefits: attaching files, commenting, voting, tracking tasks e.t.c.

Due some asshole started spamming tracker, now (at least for some time) it’s not allowed to create anonymous tasks. Sorry for unconvenience.

In edit fields you can use DokuWiki syntax for formatting.

Tasklist

FS#187 - OnClick => Notify ?

Attached to Project: Koda
Opened by Chris Haslam (c.haslam) - Sunday, 27 February 2011, 08:14 GMT+3
Last edited by Admin (Lazycat) - Thursday, 05 May 2011, 14:02 GMT+3
Type Feature Request
Category Application
Status Assigned
Assigned To Admin (Lazycat)
Operating System All
Severity Low
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

I don’t see why OnClick brings up a dialog.

It only has two values: Notify and don’t notify.

It seems to me that it would be more obvious if it were called Notify and its values were True and False. It would then work like, for example, Enabled.

Just a thought.

This task depends upon

Comment by Chris Haslam (c.haslam) - Monday, 28 February 2011, 07:27 GMT+3

I have been thinking some more: too much thought can be dangerous!

Normally, a user wants Cases (or Click Functions) to be generated for most controls. So perhaps OnClick (aka Notify) should default to True for controls like Radio and Checkbox, and default to False for Labels. This would, I think, satisfy the guy who requested Generate events for all controls.

I have just discovered that TATab has an OnChange property. I think it too should be Notify. I am thinking of adding to the documentation for OnClick/OnChange/Notify what code OnClick/OnChange/Notify generates.

Comment by Admin (Lazycat) - Monday, 28 February 2011, 13:56 GMT+3
It seems to me that it would be more obvious if it were called Notify and its values were True and False. It would then work like, for example, Enabled.

In current implementation both modes reuse the same property, so you can switch between modes at any time. In order to work as True and False, property must be boolean, while for events it's string. Property can't have different type in different cases.

So perhaps OnClick (aka Notify) should default to True for controls like Radio and Checkbox, and default to False for Labels. This would, I think, satisfy the guy who requested Generate events for all controls.

Not bad idea in whole, but this also will create events and functions. Also, someone may need this, someone not.

Maybe, better have some list (in options), where user can select, for which control create events automatically. This should satisfy everyone, and at least will have more sense then "create events for all controls".

Comment by Chris Haslam (c.haslam) - Tuesday, 01 March 2011, 08:00 GMT+3
In current implementation both modes reuse the same property, so you can switch between modes at any time. In order to work as 
True and False, property must be boolean, while for events it's string. Property can't have different type in different cases. 

I haven't used Tab controls in AutoIt, so I am a little out of my depth. Both OnClick and OnChange offer:

  • if Current Form Generating Options is not selected, Event Editor offers None or Notify
  • if Current Form Generating Options is selected, Event Editor offers None or an Input control, with the expected default value.

So, yes, I see that OnClick and OnChange have a boolean value at times and a string value at other times. So, as Koda is now, OnClick and
OnChange do need a string value.

But is this necesary (and desirable)?

To me, because the user has to choose Message Loop or OnEvent mode before setting OnClick and OnChange, so the cart is preceding the horse! Normally, a user chooses a Mode just before he generates code.

To my knowledge, this is the only place in Koda where this occurs.

It seems reasonable to me that an OnEvent function have as its name the Name of the control with Click (or Notify) appended.

I cannot see why a user would want to customize the name of the function.

Further, my experience in writing small applications with AutoIt is that it is very hard to avoid making Names of controls global where there are multiple forms which run in MessageLoop mode. These forms have 20 or 30 controls. My coding practice is to limit a function to about 30 lines, so I need to code the GUI in one function and split the message loop into several functions.

Variable scope to me is a weakness of AutoIt. In VB5/6, a variable (or a function) can be Private to a module, i.e. it is global but is only visible in the module. This time Microsoft got it right! In AutoIt, placing each dialog in its own .au3 file does not limit the scope of global variables (or functions) to the .au3 file.

So OnClick/OnChange have equivalent scope problems in MessageLoop and OnEvent modes. Consider a control named chkCat. If the user has two dialogs in a script, which both have chkCat controls, he will have two lines of code that say $chkCat = GUICtrlCreateCheckbox .... It is true that he can reuse a global $chkCat, but this is not good coding practice. So the wise programmer makes the Names of these controls different, e.g. $chkFooCat and $chkBarCat, where the forms are named Foo and Bar.

So the naming problem that being able to specify the name of the Click function solves also occurs in both MessageLoop and OnEvent as Koda is now: because both generate $chkCat = GUICtrlCheckbox .... (Actually, OnEvent mode does not need $chkCat =.)

I think Koda should have two modes for OnClick/OnChange values:

  • basic: the values are True and False to the user, even though they are strings internally.
  • advanced: the values are a string or None.

To me, OnClick and OnChange are doing the same thing but for different controls: they are notifying. The documentation would explain what OnChange does in detail. The Tab control is complicated.

In current implementation both modes reuse the same property, so you can switch between modes at any time.

I'm not sure that both modes use the same value for the property. What happens if I select OnEvent mode, enter chkFooLucas in OnClick, then change to MessageLoop mode, then change back to OnEvent mode. Does OnClick still have the value chkFooLucas? (BTW our black cat is called Lucas.)

I hope that you are still reading! I will read your reply with interest.

Comment by Admin (Lazycat) - Tuesday, 01 March 2011, 22:15 GMT+3
It seems reasonable to me that an OnEvent function have as its name the Name of the control with Click (or Notify) appended.
I cannot see why a user would want to customize the name of the function.

Seems you missed the other point of this dialog. This is not only for renaming event. This populate the list of existing events and allow select it. So, with this you can reuse the same function in many controls, and it's the place where renaming become useful. This is frequently needed thing, and I'm not going get rid of it.

I think Koda should have two modes for OnClick/OnChange values:

Property inspector editor is rely on actual property type. Dropdown list with True/False is for booleans only, for strings it's can be plain editor or custom one. I only can agree, that boolean-like editor is would be better for simple notifying. I'll look if this possible to make simpler boolean-like editor for string type, but not promise.

What happens if I select OnEvent mode, enter chkFooLucas in OnClick, then change to MessageLoop mode, then change back to OnEvent mode. Does OnClick still have the value chkFooLucas?

Exactly. In loop mode it's still string, but for being True it's should not be empty.

I hope that you are still reading! I will read your reply with interest.

A lot of words this time, but I still reading ;-) Have no time right now for implementing all the things that we come to agreement, but this is useful discussions anyway.

Comment by Chris Haslam (c.haslam) - Wednesday, 02 March 2011, 05:55 GMT+3

Discussion is important. I know how hard it is to design an application with no feedback! The ideas I am presenting to you have arisen as I work my way through the documentation. I seem to have more time at the moment to work on Koda than you do. That's AOK.

I really appreciate Koda: it is a significant advance for AutoIt, and for PerfectScript.

After thinking for a while longer, I still like the idea of Koda having two modes: basic and advanced. There are situations where one needs to create a form or dialog as quickly (and easily) as possible. Basic mode would satisfy this requirement.

Here is a way of preserving Koda's independence of AutoIt Mode until code is generated. The screen shot intentionally shows the ComboBox and Default button disabled.

It would mean that Event Editor has the same controls in OnEvent mode and MessageLoop mode.

I suggest that OnClick have two values: blank or the name of the OnEvent function, independent of whether GUIOnEventMode is set. The documentation will show what OnClick generates in each AutoIt mode.

One of these values would always show in Object Inspector.

So the horse is always pulling the cart, not being pulled by the cart at times!

Comment by Admin (Lazycat) - Thursday, 03 March 2011, 13:00 GMT+3

I (seems) see the idea with dialog, but not yet understand where basic/advanced mode come. Also, I doubt that event name visibility in property inspector in loop mode made work move obvious.

Comment by Chris Haslam (c.haslam) - Monday, 07 March 2011, 06:29 GMT+3

I suggest that you forget my idea of basic/advanced mode.

Here is another suggestion for the Event Editor dialog. It would make things very obvious.

Object Inspector OnClick/Notify, when notification is turned on, could show the name of the control when in Message Loop mode and the function name when in OnEvent mode.

Comment by Admin (Lazycat) - Friday, 11 March 2011, 16:23 GMT+3
Here is another suggestion for the Event Editor dialog. It would make things very obvious.

Hm, I like this idea. Dialog is really looks obvious. Not quite sure about showing actual names in property inspector, but we can give a try.

Comment by Chris Haslam (c.haslam) - Saturday, 12 March 2011, 08:47 GMT+3
Not quite sure about showing actual names in property inspector, but we can give a try.

I'm not sure either. I think that you don't want to use True and False, because of confusion with properties that are boolean. You could use "Yes" and "No". The advantage of Yes and No is that something shows in the Value column even when notification is off.

BTW how do you show a quote? I put it between code and /code.

Comment by Admin (Lazycat) - Saturday, 12 March 2011, 12:40 GMT+3
I'm not sure either. I think that you don't want to use True and False, because of confusion with properties that are boolean. You could use "Yes" and "No". The advantage of Yes and No is that something shows in the Value column even when notification is off.

Ok, I'll think.

BTW how do you show a quote? I put it between code and /code.

In DokuWiki syntax (which is also used here, in commenting) it's e-mail style. Put ">" at line beginning - following text will be formatted as quote. Then separate your own answer by one empty line.

>Quote

Answer
Comment by Chris Haslam (c.haslam) - Sunday, 13 March 2011, 15:49 GMT+3

Thanks

Loading...