View previous topic :: View next topic |
Author |
Message |
vdsalchemist Admin Team
Joined: 23 Oct 2001 Posts: 1448 Location: Florida, USA
|
Posted: Sun May 29, 2005 5:00 pm Post subject: @event() Bug with the '|' character |
|
|
Hi Jules,
It seems that @event() truncates the string that is sent to it if it finds the '|' character. This happens in VDS 5. It does not matter if your using the @event(D) option for multiple dialogs or not. I also tried encapsulating the text in quotes but that did not work either it still truncates the string. Shouldn't the @event() function only parse the string if it has the D option?
Second part is just a wish. Can you have it ignore the parsing if there is quotes around the string being sent? _________________ Home of
Give VDS a new purpose!
|
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon May 30, 2005 8:57 am Post subject: |
|
|
This is part of the changes in VDS 5 to allow externals to send more information. The | is used as a separator for the information, so it cannot be used in the name of an event. Extra information may be sent regardless of whether the D option is used. @event() only controls the information obtained by the script when you call the function. When the event occurs, many information may be sent, such as mouse co-ordinates when a click occurs, which must be stored by VDS in case required by the script, whether it is actually used or not.
No notice of quotes is taken when the information passed from an external is accepted by VDS. The | is the only delimiter. Events may be very frequent and time critical, so their processing must be as efficient as possible. VDS is already too slow to handle some types of event-intensive activities.
If you need to pass more complex information when an event occurs, the way to do it is to generate a simple event, and then have the programmer call a function when the event occurs that retrieves the other information. That is the way the external interface was designed to be used. You are trying to use it in a way it was not intended to be used, so it is not fair to say that VDS has a bug because it does not work in the way you expect.
The external interface changed in VDS 5 to allow greater possibilities with externals, and will change again slightly in VDS 6 to make things a bit better. Externals that work with VDS 5 should still work. I am sorry that CR did not publish the details of the changes but that is something outside my control. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
vdsalchemist Admin Team
Joined: 23 Oct 2001 Posts: 1448 Location: Florida, USA
|
Posted: Thu Jun 02, 2005 3:07 am Post subject: |
|
|
Sorry Jules,
I don't think I explained this right. Let me try again.
If I send an event formated like so.
Data1|Data2|Data3|Data4
The @event() function truncates the event to
Data1
If I use @event(D) the function truncates the event to
Data1|Data2
I can understand why the @event(D) truncates the string sent because it is parsing the string for EventName|DialogID but the reason I thought it was a bug is because the @event() function without the D option is parsing the string but truncating the string to just the first item. So my guess is your parsing the string Data1|Data2|Data3|Data4 before you determine if the VDS user used @event(D) or not.
Also in some situations it is impossible to send just the name of the event and then have a different function to return the values for the event. In my situation it would require me to queue up the event names and the values. So now the processing of events just got twice as long. It is always quicker to just wait for 1 queue than to wait for 2 queue's. Don't get me wrong I love the idea that VDS 5 queue's events.
Anyway I have a work around. I just replace the '|' characters with '~' and keep going since what I am sending @event() is smallish data and not a book. _________________ Home of
Give VDS a new purpose!
|
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Thu Jun 02, 2005 8:06 am Post subject: |
|
|
I understood perfectly.
dragonsphere wrote: | So my guess is your parsing the string Data1|Data2|Data3|Data4 before you determine if the VDS user used @event(D) or not. |
That's exactly right. The string passed from the DLL to the main runtime is parsed when the event occurs. The script will call @event() some time later.
Up to 4 items of data may be passed by the DLL to the runtime, such as the ID of the dialog causing the event, the mouse co-ordinates and so on. They are passed in one string using | separators in order to use the same original extension API from VDS 2 without changes. It would have been more elegant to create a new improved API for VDS 5 extensions, but that would have been incompatible with older ones, and it would not have been possible to use them.
So the information you're passing in the event name, separated by |'s, is being interpreted by VDS 5 as its own information. Conceivably, it could actually cause an error, since the interpreter assumes that the information is coming from something that knows the format it should be in, and therefore does no validation.
If you need to abuse the event passing interface in this way, your solution of using a different separator character should not, as far as I can see, cause a problem. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
Skit3000 Admin Team
Joined: 11 May 2002 Posts: 2166 Location: The Netherlands
|
|
Back to top |
|
|
vdsalchemist Admin Team
Joined: 23 Oct 2001 Posts: 1448 Location: Florida, USA
|
Posted: Thu Jun 02, 2005 1:55 pm Post subject: |
|
|
Skit,
That's not really going to help. That not the issue I have. The issue I have falls back to Threading. If I pause my function that is firing the events to wait for another function to get the event it locks VDS since they are both using the same thread. Jules is right I just didn't know since it was never documented. My only other option would be to build a queue to hold the events and allow a second function in my DLL to pull the data off of that queue when VDS'es @event() function gets the event. The only issues is this. On the one hand I don't want to delay the delivery of my DLL to build this queuing system. On the other hand I don't want to set a precedence and everyone writting their code to parse and swap characters. While the main issue is not really any of these things as much as it is for the fact that I have a single function that is handling events coming from multiple sources and each event can have different names. I am sure that when Jules was writing VDS he pondered many of these same issues.
Thank you Jules for taking the time to explain it to us. I do appreciate it.
I think this thread is done. It is not a bug after all. I don't know how to lock the topic so I will have to leave it up to the VDSWorld gods to do this for me. _________________ Home of
Give VDS a new purpose!
|
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Thu Jun 02, 2005 3:49 pm Post subject: |
|
|
VDS 5 has its own list for queuing events.
I wonder whether you considered using windows messages to generate events, which are queued by VDS?
If you define your message using OPTION MSGEVENT, then an event is generated whenever this message is sent to the application window. VDS will store the value of wparam and lparam along with the event, and these values can be read using the @MSGPARAM function. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
vdsalchemist Admin Team
Joined: 23 Oct 2001 Posts: 1448 Location: Florida, USA
|
Posted: Thu Jun 02, 2005 6:30 pm Post subject: |
|
|
Jules,
I would do that but it does not work very well. First, you would only be able to use my DLL with VDS 5. Second, I have had issues with VDS 5 not able to see USER defined Message ID's. I used the RegisterWindowMessage Win32 API function to register a user defined message ID but VDS 5 does not always see the message. Third, My DLL already has the ability to hook API messages but neither VDS'es nor my DLL's message hooks are simple enough for the average VDS user to use. I have had many people ask me how to use the mechinism.
Anyway I implemented a Queue to store the event values within my DLL. Now it will just send VDS the name of the event and the programmer can call a separate function to pull the value of the event off the queue. It was actually easier than I thought and did not take that long todo. So now as VDS queue's the event name my DLL queues the event value(s). When VDS @event() returns the name of my event the programmer can call a function in my DLL to grab the value(s) of the event and assign or append the return to a VDS List since the value is formated like VDS List. _________________ Home of
Give VDS a new purpose!
|
|
Back to top |
|
|
|