forum.vdsworld.com Forum Index forum.vdsworld.com
Visit VDSWORLD.com
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


@event() Bug with the '|' character

 
Post new topic   Reply to topic    forum.vdsworld.com Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
vdsalchemist
Admin Team


Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA

PostPosted: Sun May 29, 2005 5:00 pm    Post subject: @event() Bug with the '|' character Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
jules
Professional Member
Professional Member


Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK

PostPosted: Mon May 30, 2005 8:57 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
vdsalchemist
Admin Team


Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA

PostPosted: Thu Jun 02, 2005 3:07 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
jules
Professional Member
Professional Member


Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK

PostPosted: Thu Jun 02, 2005 8:06 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Skit3000
Admin Team


Joined: 11 May 2002
Posts: 2166
Location: The Netherlands

PostPosted: Thu Jun 02, 2005 8:47 am    Post subject: Reply with quote

You might also be able to extend the Evloop a bit to your own needs: Smile

Code:
:Evloop
wait event
goto @event()

# This event will be called by your dll:
:MyEvloop
goto @mydll(event)

_________________
[ Add autocomplete functionality to your VDS IDE windows! ]
Voor Nederlandse beginners met VDS: bekijk ook eens deze tutorial!
Back to top
View user's profile Send private message
vdsalchemist
Admin Team


Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA

PostPosted: Thu Jun 02, 2005 1:55 pm    Post subject: Reply with quote

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. Wink

_________________
Home of

Give VDS a new purpose!
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
jules
Professional Member
Professional Member


Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK

PostPosted: Thu Jun 02, 2005 3:49 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
vdsalchemist
Admin Team


Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA

PostPosted: Thu Jun 02, 2005 6:30 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    forum.vdsworld.com Forum Index -> Bug Reports All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum

Twitter@vdsworld       RSS

Powered by phpBB © 2001, 2005 phpBB Group