A gaggle of suggestions

[Chris Cullen]

1. An array of all the controls placed on the form at design time.  That makes parsing each control on the form easier for global operations.
2. In propertys for controls, the ability to enter a call back procedure name - makes sub or super classing easier!
3. ADO Data aware text box/check box/combo box etc!
4. Ability to set properties for multipal controls
5. Functions to set/get values for calendar and datetimepicker controls

It would also be great if a text field could be associated with a control.  In VBA and Foxpro this is called Tag, and I use it a lot for storing extra info for a control.  I have no idea of the best way to do this, but would probably require some extra coding for each control's callback.

Combined with the array (which is similar to the VBA controls collection) it allows a lot of work to be done in a for...next loop rather than loads of repeated code for each control!

Just some thoughts!  

Also, on the code editor, can we have a means to find out the full file path and name, perhaps in a tooltip for each modual?  Its easy to mix up between LAN based and local based files!

Thanks

[TechSupport]

Hi Chris,

Thanks for the suggestions. I will reply to each with my thoughts.

1. An array of all the controls placed on the form at design time.  That makes parsing each control on the form easier for global operations.

I know what you mean. You can simulate this right now by creating a global array of DWords and add each control's handle to each array in the WM_CREATE message. Probably not the best solution but it would work. In the longer term, it would be nice if FireFly handled that itself.

2. In propertys for controls, the ability to enter a call back procedure name - makes sub or super classing easier!

No need. FireFly already subclasses every control automatically so you already have total control over all the controls. You can add any code related to manipulating the control in the various messages for the control. If the message is not explicitly available then you can put it in the CUSTOM message.

3. ADO Data aware text box/check box/combo box etc!

Good suggestion but I seriously doubt that this will find its way into FireFly in the near future. Sorry.

4. Ability to set properties for multipal controls

Yes, I have heard that one before. Not an easy thing to do given the way that the PropertyList is designed.....

5. Functions to set/get values for calendar and datetimepicker controls

Yes, good idea for sure.

It would also be great if a text field could be associated with a control.  In VBA and Foxpro this is called Tag, and I use it a lot for storing extra info for a control.

This was mentioned a long, long time ago but I never did add it to FireFly. I used to use it in VB years ago. I know how to do it - simply add a couple of FireFly functions to set and get the text. When setting the text dynamically allocate the string memory via HeapAlloc and then free it when no longer needed. Not overly difficult.

Also, on the code editor, can we have a means to find out the full file path and name, perhaps in a tooltip for each modual?  Its easy to mix up between LAN based and local based files!

Yes, good idea. I think that the Explorer in the Workspace dialog is the only place where the path is currently displayed.

[Chris Cullen]

Thanks for the detailed response.

I guess what I was after with the ability to set the callback was I wanted to avoid a situation which I now face!  (alway a good motive)

Anyway, I have a form with a zillion text boxes on (at the last count) and each one relates directly to a ADO field! (You can see where this one is going I'm sure)

Anyway, I don't relish the prospect of having to create a custom function for EVERY control when all that function will do is call anther one passing the same parameters as it got!  Now, if I use the form's custom event and test for the textbox controls, I then need to know what that control relates to etc (this is the ADO aware bit and the text association bit).  I guess I could write a form custom event and use that to create lots of properties for each textbox which can then go on to be used for generic message handling - but this is all getting a bit messy!  Its also a pain to remeber how it all works in six months when I need to update things  :evil:

I wondered if there could be a way to just create a single function to handle custom messages for a type of control and then tell FF to call that, instead of looking for a custom function for each control.

Mabey I'm just a lousy programmer and too bloody lazy to boot!  But, that is where this all came from - ho hum.

:?

I guess that at the end of it all, having ADO aware controls and a Data aware form would be the answer.  In terms of productivity, you'd get a hell of a lot more done if that burden was handled by the FF code generator.

Still, when I consider the alternative to FF, then it all seems a lot more manageable.  FF really is a great job you know!   :lol:

[TechSupport]

I wondered if there could be a way to just create a single function to handle custom messages for a type of control and then tell FF to call that, instead of looking for a custom function for each control.

I believe that a ControlArray is what you need. Create your text boxes all with the same name. Set the "ControlIndex" to a different value for each control. This way you can differentiate the control from the others when its custom functions are called.

There is a topic in the help file on Control Arrays.

If you implement Control Arrays then all messages get sent to the same function. For example, look at the WM_CHAR message below:

Code Select Expand


Function FORM1_TEXT1_WM_CHAR ( _
                            ControlIndex  As Long,  _  ' index in Control Array
                            hWndForm      As Dword, _  ' handle of Form
                            hWndControl   As Dword, _  ' handle of Control
                            chCharCode    As Long,  _  ' character code
                            lKeyData      As Long   _  ' key data
                            ) As Long

End Function

Notice the ControlIndex function parameter. Use that value to act on the textboxes (probably via a Select Case statement).

[Chris Cullen]

Spot on Paul!   I'd totally forgotten about control arrays!

That'll do nicely   :wink:

[Roger Garstang]

I totally agree with 2 and 4.  When I got him to process the CUSTOM message the way they are now it made a big difference, and he is right about them being subclassed and that pretty much takes care of 90% of them...except the controls added by right clicking the form like Statusbars, etc.  These are really needed especially since lately I've been making a lot of controls children of other controls (Progressbars in Statusbars, controls children of Frames, etc.) which would be another awesome FF addition so I don't have to do it in WM_CREATE, etc.