Trigger conditions window name

Hi,
opening the trigger conditions window to edit our conditions, especially if a lot of triggers exist, many times I forget whose trigger the conditions I am editing.
It should be very helpful if "Trigger conditions" on the windows header to write the name of the trigger something like [trigger name] - trigger conditions.

Best Regards,

Theodore

Thank you Theodore, I'm surprised that I didn't think of it before. I'll add this to the next release.

Whilst on the subject of triggers a couple of "nice to have" ideas:

When saving conditions in a large block of triggers (expecially those containing links to text files) if you open the next set of triggers too quickly the window opens and collapses imediately - never to be seen again until you restart MF pro.  An "hour glass" timer showing that it is still 'thinking' would be helpful.

Secondly - if you delete a trigger you are asked if you are sure whilst if you delete a trigger block you are not - a consistent approach would be good.

Thirdly - you can click and drag a trigger around - would it be possible to enable you to drag a whole block of trigggers up or down within the file ?

Also - it would be good if you could drag conditions up and down in the conditions window.  If you forget to include one at the top it is difficult to shuffle the others around later.

It would be nice if the opposite of "are met" was spelt right - last time I looked it said "ae not met".

It would be good if the scroll function on the mouse either allowed you to scroll up and down the triggers or was entirley disabled.  As it is at present, if you scroll accidentally you can change one of the drop down boxes without realising so when it was previoulsy set to "are met" for intance it can become "ae not met".

Hope these are useful.

Nice suggestions, Alfaman.

I would also add the ability to open several trigger "snippets" (blocks) into a complete trigger file (in other words, combining several trigger files into one). This is useful when developing ideas using standard techniques such as fill or kill, auto-greenup, etc.

Hi,
a big part of our suggestions have to do with interfacing.
I understand that, they can be implemented, according to the limitations of MF interface framework and available manpower also, even if, your programming team is very qualified and willing to do everything.
That means, in many cases usability and interface that is obvious under Windows Forms Foundation (others paid for that), in MF have to be  programmed from scratch (or somewhere there).
For the most of us, it might be easy to shoot with new suggestions whenever they come in mind and as we come from the Win world we think it migth be easy to implement, but, in your framework it might not.
Also, a programming language intrinsic to Windows, I mean a Visual Basic addon to MF, could extend and cover MF object model, giving us in addition a true programming environment.
Did you ever think to migrate MF as a Windows app?

Best Regards,

Theodore

Alfaman, thanks! It is all very fair, and I will add it to the next or one of the future releases.

Hi,
a big part of our suggestions have to do with interfacing.
For the most of us, it might be easy to shoot with new suggestions whenever they come in mind and as we come from the Win world we think it migth be easy to implement, but, in your framework it might not.

It certainly is a good idea.

Also, a programming language intrinsic to Windows, I mean a Visual Basic addon to MF, could extend and cover MF object model, giving us in addition a true programming environment.

Theodore, do you have a basic scheme of how you would like to implement this add-on? What kind of functions and interaction with MF Pro would you intend to program inside the add-on?

Hi OXA,
first of all you have to sign a VBA partnership with Microsoft, so that you can have a Microsoft VBA 6.5 licence to use with MF Pro.
Actually this licence is distributed and managed from Summit Software (www.summsoft.com).
In the future VBA licence will be offered as VSTA (www.summsoft.com/products.aspx) and slowly VBA will be discontinued with VSTA in its place.

You must write your object model for VBA, and, all properties and methods of MF object architecture (functions and user variables in the existing system) might be called via VBA.

A (new) equivalent triggers window metaphor will exist also under windows. We will be able to run a trigger file, or, we will have the possibility to generate VBA code for the trigger file and then insert our vba code to that if we like. Something like the generated vba code from excel we have in an Excel macro.

Such a system will have automation and integration with Office, with endless possibilities.

You could give the possibility at third parties to produce extensions for MF.

The new windows interface will be based on Windows Forms foundation.


Best Regards,

Theodore