jiri wrote:As for dropdown - ok, these properties will be added.

Great! Thanks.

No, it isn't possible to cancel the input here.

As for dropdown - ok, these properties will be added.

Jiri

ISDBUICommonEvents::OnKeyPress
Sub OnKeyPress(Key As String)

This event is called when a key is pressed.

Introduced in MediaMonkey 3.1.0.1221

Do this new event has a possibility to cancel input? Here is what we have with Visual Basic: "Keyascii is passed by reference; changing it sends a different character to the object. Changing keyascii to 0 cancels the keystroke so the object receives no character."

By the way (not related to this topic), it is nice that you added SelStart, SelLenght and SelText to the Edit and MultilineEdit controls, but it would be nice too if you add same properties to the Dropdown control which has a Style = 0. I really need them in my RegExp F&R script where I want to insert programmatically some text to the edit field of dropdown control where is a textual cursor.

I agree that as long as the event order is in the wiki then it doesn't matter what it is (as a web developer this is something that browsers often do differently so you have to be careful) and is probably best to stick with the underlying language rather than try and work against it.

Sure, scripts are written in VBScript. I just wanted to say, that the calling order of events is based on how is it implemented in Delphi and changing the order doesn't seem to have any good reason, not mentioning possible bugs introduced.

I believe that the arguments of OnMouseMove event have very good sense: the event says that mouse pointer was moved and only adds information about all buttons that are pressed at the moment. For example, there can be both left and right mouse button pressed and ShiftState parameter can very well handle this, while Button argument of OnMouseDown and OnMouseUp specifies a single button that was just pressed/release at that moment.

Jiri

We script developers are using VBScript programming language. It is made by Microsoft as limited variant of Visual Basic and has similar syntax as VB. It has almost nothing in connection with Delphi. So, I think that your API functions/events should follow Visual Basic logic, not Delphi.

ShiftState is argument that should tell us which shift key is pressed (Shift/Ctr/Alt), in combination with some another key. That another key should be found by Button argument, not by ShiftState. Why don't you use same arguments with OnMouseDown and OnMouseUp? Why those events have Button arguments if it is possible to get that information from ShiftState?

Answer to both issues 1&2 is the same - the events are based on Delphi events and so the call order and parameters are the same as in Delphi. Note that ShiftState parameter can be used for getting info about the pressed button.

As for OnKeyPress, I don't think it's overly important, but ok, will look into it and probably add it.

Jiri

You are correct Noted here.

Thanks so much to MM developers for those new events. However, I have some complains about them, considering same events within Visual Basic.

1. OnMouseMove should have Button argument as OnMouseDown and OnMouseUp, i.e. it should be Sub OnMouseMove(Button As Int, ShiftState As Int, X As Int, Y As Int)

2. In Visual Basisc when we click on some button, we have the next order of events:
- MouseDown
- Click
- MouseUp

With MM button we have the next order:
- OnMouseDown
- OnMouseUp
- OnClick

Also, when we press a key on some button in Visual Basic (and hold it some time), we have the next order of events:
- OnKeyDown
- OnKeyDown
...
- OnKeyDown
- OnKeyUp
- OnClick

With MM button we have the next order:
- OnKeyDown
- OnKeyDown
...
- OnKeyDown
- OnClick
- OnKeyUp

Well, this second issue with the executing order is not very important if you know what you are doing, but the first one with missing argument could be problematic in some situations.

By the way, when you added such fine events why you didn't add OnKeyPress as well?