Event structures casees large

[Wise700]

Hi All,

I have been working on an application where there is extensive user events and corresponding actions need to be taken.

I'm using event structure to capture those events in while loop. But the number of cases in event structure is increasing ( Now has reached 50 cases, most of it are like disabling a control on click of button).

Does this effect the performance? As only one case will execute at a time.

Is there any architecture where all the UI related events are handled more efficiently. I have been reading about the producer consumer architecture , but still number of cases in event structure would  be same and the actions in consumer loop with equally number of cases.

How do experienced programmers deal with this sort of issues as one's application becomes large and complex.

Any pointers of what i'm doing worng would be much appreciated

[GerdW]

Hi Wise,

Does this effect the performance? As only one case will execute at a time. (most of it are like disabling a control on click of button)

Well, how many buttons can you press at the same time? 😄

deal with this sort of issues as one's application becomes large and complex

Work with references. Create events to process same action on several controls instead of creating an event for each button/control combination…

[Norbert_B]

Well, if the application requires many events, it requires it, no?

Just to mention some things:

- How many controls are there for the user to interact with? I am not sure if that should exceed 50 on a single panel.....

- How many programmatic events ("user events") does your application need? That could be the trickier question....

- How many event cases do you have which contain very similar code? I hope: None. Otherwise, please merge those cases.....

How do other developers address this?

Most often, by selecting a more powerful architecture than a single event handler. Moving to producer/consumer or the derived "Queued driven message handler" could be a step in better "dosing" event cases to parts of the software.

Also, plugin architectures with subpanel controls can reduce the number of event cases in a single event structure.

Norbert

[Yamaeda]

As an addition to the previous, 50 is no problem, unless a single event takes a long time.
Finding the correct event to execute seems to be a linear search of flagged event vs registered events. You can make a list of 50 strings and test how long a "find in array" takes. It's in the microsec range.
/Y

[Wise700]

Thanks all for the replies.

I didn't get what GerdW  meant by

"Work with references. Create events to process same action on several controls instead of creating an event for each button/control combination"

Can i get an example of how to do that?

To answer Norbert_B  questions

-How many controls are there for the user to interact with? I am not sure if that should exceed 50 on a single panel..... there are 50 events, i have cursor move cases, I have attached thescreenshot of the cases i have. And its large number is kind of bugging me

- And about moving to a better architecture.. as it now a quite a big application , starting out with new architecture would be very cumbersome right? is there any other way?

Thanks for all the help.

[Norbert_B]

Changing the architecture for an existing application is indeed quite worksome. But sometimes inevitable.

That being said, the question if 50+ cases are suitable in a single event structure is not necessarily a reason for scrapping the existing architecture. The biggest questions are:

- How many cases do you expect to add in the (near) future?

- When you added all those cases: Do you think that someone without a detailed knowledge of the application (but good LV knowledge) can maintain your code?

If you feel that the second question can be answered with "yes", there is no imminent reason to swap architecture. If the answer would be "no", you might want to recommend a rework of the complete application. Sure it takes time and resources, but on the long term, it might reveal itself as a very prudent decision....

Norbert