Leaderboard

In case you missed the Aussies getting a clinic over the weekend (I'm talking to you Crelf!), here is the recap: http://www.youtube.com/watch?v=yRu0ePLlqgY&feature=player_embedded"'>http://www.legofussb...mbedded

I can't give you an exact number, but the answer is "more than you should ever need." To be honest, I think you're basing your decision on the wrong criteria. Events and queues can both be used to transmit data to parallel loops, but they have different purposes. Events are used in a "one-to-many" situation. You have one event source and many event consumers. Queues are used in a "many-to-one" situation. You might have many sources enqueueing messages, but only one consumer dequeuing messages. If you have a "one-to-one" relationship you can use either, but queues are easier to work with. I try not to think of it as an "event queue" because the event structure doesn't necessarily process events in the exact order they were received. (Ton knows more about that than I do.) Plus you have no way to manipulate the "event queue." Think of it as an "event handler" instead. When using events it is better to set up an event structure in a loop to receive events and then send messages and the event data (via a queue) to a parallel loop to do the actually processing. That way your event handler stays free to process events as they come in and you don't have to worry about events stacking up. When is it a good idea to use events? The first is obviously when you have to process the user's fp input. The Producer/Consumer Design Pattern (Events) template is a good starting point for that. I also use events when I'm writing asynchronous code modules as a way to notify clients of things they might be interested in. Personally I haven't found events particularly useful in other situations, mainly because of the edit time overhead associated with them. Uhh... neither. I know lots of people tout the virtues of the Queued State Machine; personally I think it's a poor pattern because it doesn't promote good design decisions. Using a queue to store sequences of states to be executed can easily lead to code that contains hidden errors and is hard to maintain. You can use a queue to transmit messages and data from the UI loop to the Processing loop, but don't use that queue to control state as well.

I guess untill the memory of your computeris full. That will happen faster with an event structure than with a queue, the overhead of the event structure includes the actual timestamp when the event happens. Ton

So I whipped up a little table that correlates the locations from 'Get System Directory.vi' and the Windows Installer variables (used with the built-in install builder) with Windows XP and Windows 7. None of the locations that you can easily get to via Get System Directory and Windows Installer are appropriate for a machine-wide config file. If you create the config file at run time instead of installing it, the Public Documents tag for Get System Directory will work. You can avoid having them show up in each users' My Documents folder by stripping "Documents" and appending "AppData\MyApp\MyApp.ini." It's not ideal, but it's workable. Windows 7 has a %PUBLIC% environment variable that maps directly to Users\Public, but that variable doesn't exist in XP so it's not much help with cross-os compatibility.

Here is a method: You have to check Draw Mode (triangles or quads) in order to know hoe to interpret Indices (refer to mesh example in LV). It's also good to check Normal Binding Mode (whether normals are defined per vertex, per face or not binded at all).