Greetings LAVA members
the coding challenge committee:...

[attachment=2934
attachment]
[attachment=2940
attachment]

...would like to announce the next LAVA coding challenge.
We are going to change things around for this challenge. Instead of having judges choose a final winner we are going to ask the LAVA members to vote on the final choice.

Review Format:
Here is how the coding challenge format will work.

• All submissions must meet a set of minimum requirements defined by the committee.
• Every submission that passes the minimum requirements will be evaluated by the challenge committee and the top 5 will be selected.
• The top 5 will be posted publiclly to all the LAVA members and a winner will be chosen by popular vote.

Challenge Definition:
The challenge that the committee has selected is called "Mouse Gestures". A mouse gesture is a technique used in a user interface that combines mouse movements and clicks. The software interprets these actions into application commands. Mouse Gestures allow quick access to programmable commands without the need for keyboard strokes or menus. The task of the Mouse Gesture Application Interface (MGAPI) is to return to its calling application the detected gesture string. It does this by tracking the mouse trajectory on the caller's front panel between the mouse down and up events. It translates the trajectory into a series of string characters to be returned to the application.

The string characters are identified as follows;
U for Up
D for Down
R for Right
L for Left,
The 4 diagonal directions are identified by the corresponding numbers on the numeric keypad.
1 for Down Left
3 for Down Right
7 for Up Left
9 for Up Right

For example, if the users presses the Mouse button and draws a "Z" on screen and then releases the button, the MGAPI returns the final string of "R1R".

Note: Mouse Gestures are not about pattern recognition but about mapping the mouse movements to a simple set of string characters. Install the Firefox Mouse Gestures extension to see it at work.

Challenge Framwork:
The Mouse Gestures challenge will consist of two parts a technical part and a creative part.

1:MGAPI:(MG Test vi)
The first part will be to create a MGAPI and place it inside a Test VI supplied by the committee. This will give the committee a standard platform to test all submissions fairly. The committee will use the test VI along with other tools to evaluate the MGAPI to the following criteria.

• Ease of portability,
• Performance,
• Scalability and Adjustability,
• Coding Style

 MGAPI_Test_Vis_6.1_to_8.01.zip ( 63.22K ) Number of downloads: 394


2:Application of MGAPI(MG Application vi)
The second or creative part will be to build a LabVIEW application that makes the best use of the MGAPI. This could be anything that you can think of as long as it uses the same MGAPI as was used in the test vi. Remember you are trying to impress your LAVA peers so the cooler the better.
Both the MGAPI and final application will be evaluated by the committee when selecting the top 5.

Minimum Requirements:
For the Mouse Gesture challenge, the minimum requirements are as follows:

• The MGAPI must intercept mouse movements from the calling vi's front panel between mouse down and mouse up.
• The MGAPI must produce two string outputs that use the 8 direction string characters UDLR1379.
• The First string indicator Labeled (MG Process) will display the direction characters as they occur in process or while the mouse button is pressed.
• The Second string indicator Labeled (MG Final) will remain empty until the mouse button is released and then display the final character string.
  

  Example:
  Referring to the Z example, when the mouse button is pressed both the (MG Process) and (MG Final) will display an empty string. After the first detected motion (MG Process) would display a "R" then a "R1" after the second and a "R1R" after the third.
  When the mouse button is released (MG Final) will then display "R1R".

• Standard LabView Coding Challenge rules apply.
  

  All coding must be done in LabVIEW (any version is acceptable).
  No external code, DLLs, CINs, exes, ActiveX, .NET, etc
  DLL's or libraries that are part of the core LabVIEW are allowed.
  OpenG code is allowed. Please include this code in the ZIP file.
  

• The same MGAPI code from the MG Test vi must also be use in the MG Application vi.

Considerations:
These Items although not mandatory should be considered when developing the MGAPI

• Minimum segment length
• Angle tolerance
• Timeout when mouse is idle.

Submissions:
The deadline for all submissions is Aug-20-2006.
The final submission should consist of a ZIP file containing the two main vis (MG Test vi and MG Application vi) along with all of the support files and VI's. Warning, ONLY ZIP files will be acceptable as attachments.
Please e-mail the final ZIP file to: codingchallenge@lavag.org. Multiple submissions are acceptable.
In the subject of the email please write MG Challenge followed by your LAVA user name.
Example: MG Challenge joe_user
Please Do not post submissions to this thread. Please use a valid email address that you check often so we can contact you for possible missing VI's or questions.

You CAN post questions to this thread.

Finally, My thanks to the committee for all there past, present and future help.
mballa

Great challenge, and I'm happy to say that I've completed the basic part of my API and am thinking of some cool apps, but I do have a couple of questions.



1. The challenge states that my application HAS to use the same API as the test VI. This strikes me as very limited. I would much rather extend my API and use more powerful features in my application. Is this not a possiblity?



2. Both dynamic events and the mouse input VIs were not available in 6.1, so obviously there's no way to make it really portable in 6.1 without writing some external code (which is not allowed by the rules ). Did you include the 6.1 template on purpose or was that just an oversight?

That's what we like to hear - glad that it's stimulating your mind

The reason we chose a simgle API for all entries is that of a level playing field - as you can see from the announcement positing, there are a number of judges involved in selecting the final five, and we felt that placing this limit on entries allows us all to have a baseline - a frame of reference - to assess your entries on. For your entry to be valid, it must work with the template API, although once this is all over and the winners announced, by all means: go nuts! You might even find someone else's submission better than yours, which will give you an even better platform to create a new version from.

Although using the event structure and mouse input VIs are native to versions above 6.1, there may be methods that you can use to complete the tasks with 6.1 (I'm not saying there are, nor am I saying there aren't ). There are still plenty of people out there that are still using 6.1 (it is a pretty stable and functional version), and we didn't want to exclude those folks from entering the challenge.

Does that mean that the only way for me to output the results to my application (not to the test VI) is through those 2 strings? Can't I use anything else?

I suppose I could output those strings to a mediator and use that to generate what I want, but that seems rather ridiculous. I would really rather add more options into my interface now (while still keeping the stings, of course) because I haven't managed to find an application where this will really be useful yet and I don't know if I'll use this after the challenge.

Thank you.



One of The reasons why we want the same API used in the test vi as in the application is to help show Ease of portability. One of the attributes that we feel makes a good API is how easy it is to insert into another application. Adding additional functionality beyond the requirements is fine but the API as a whole should be transportable to other applications.



We wanted to let anyone with version 6.1 or greater be able to participate if they wished. A submission written in any of these Version is acceptable.





The strings are to insure a minimum requirement and give the committee a standard interface to use for testing. They do not have to define the Functionality of the API. It is not required that the string outputs be the only way that the API transmits it's information. The string outputs must be a part of the API.

That's what I wanted to hear. Thanks.

P.S. I missed some words in my reference to 6.1 - I meant to say that there is no way to make it truly independent from the calling VI and portable without writing external code and compiling it for every target (at least none that I could think of, which isn't to say that there isn't).

This post has been edited by yen: Jun 26 2006, 07:58 AM

what do you mean by "Timeout when mouse is idle"
the timeout will stop the mouse tracking by starting the application VI or it will clear it and restart the registration
(sorry for my poor english )

Since this isn't a mandatory requirement, that would be up to you. The way I understand it (or at least what I thought before I read that line) is how long does the cursor have to stay in one place before you stop calculating a movement.

I assume that MG Final indicator displays empty string in the very next loop after the mouse button is released. Is that right? Or MG Final should keep displaying the "R1R" in the following loops?

Zen

MG Final should retain the last MG sequence ("R1R") until the mouse button is pressed again.

Hi Folks,
Thanks for the challenge! (you've lured me away from the NI LabVIEW Forum)

Any way, it seems obvious (now ) that the VI is supposed to execute immediately, but as it's not explicitly stated anywhere, I thought I'd ask!(?)

I'm about to trash a VI that was designed to return a completed "Final" string - wouldn't terminate until a mouse-up or mouse-leave (or caller "Stop"). But the requirement as to the empty-state of Final, while mouse is down, implies that our VI executes immediately, so it seems our VI shouldn't wait for mouse events...

Thanks!

How about sending confirmation emails or publishing the names and dates of the submitted entries so that we know that our submissions got through alright (or didn't)?

all submissions are collected by mark ("mballa") and posted in a forum, which is not public. I do not assume that mark holds back any submissions , so I can state that - if you did not get email yet, that your submission does not meet the minimum requirements - your submission is in the reviewing process and - if it's among the top 5 - put on the list for the public election