WestcountryBusiness
asked on
Event Driven Programming in VB.Net - Fundamental Understanding
I'm a relatively experienced (well, old) programmer using VB.Net, usually WinForms applications. I have a project to write code to automate a weighbridge (used for the weighing of vehicles). It's a console application.
The weighbridge will have 3 sensors.
1- the Front to signify something moving on to the weighbridge
2-Near the other end that shows when the front of the vehicle is far enough forward to be sure it is completely on, and
3-The rear to signify if the vehicle is leaving (or is too far forward if it didn't stop in position)
There are traffic lights in place that I set depending on the position of the vehicle (sensor triggered). However events may not always be triggered in the order I expect and I'm not sure if I'm handling the code correctly.
Here's an example:
1. When the code starts it runs 'Set Weighbridge Normal' - that sets everything to default values, turns on sensor 1 linking to the event handler 'LorryApproaching' and sets the lights green, then waits ...
2. The lorry pulls onto the Weighbride, sensor triggers, code moves to 'LorryApproaching' that turns on Sensor 2 (link to event 'InPosition') and sensor 3 (linked to 'LorryLeaving') and leaves sensor 1 on aswell as you just don't know what some drivers will do!
3. Lorry triggers in position, which in turn tried to identify the lorry, wait till the weighbridge is stable then take a weight.
What if, at this time, the driver doesn't wait and drives on. During 'InPosition' we are now in 'LorryLeaving'. LorryLeaving will know no weight has been taken so will try and get the driver to back up. Hopefully back to retrigger 'In Position' from the start but he could drive off so after timeout the weight is checked and if there's not weight on the weighbridge, it's recorded as potential missed load and we call 'Set Weighbridge Normal'
Here's my concern. It feels like I should be letting the code run through each event to a conclusion so that each can wind back down again till it naturally finds it way back to Set Weighbridge Normal. I'm ultimately calling 'Set Weighbridge Normal' as the result of one or more events that took me out of 'Set Weighbridge Normal' in the first place.
In my old fashioned mind, I see a calling stack getting ever bigger till I run out of memory (sorry, old school programmer here). Is that a real concern of does good old VB.net handle that all for me so I don't need to worry?
If I don't call 'Set Weighbridge Normal' after the vehicle leaves, in the case that sensor 3 was triggered during 'InPosition' when it was trying to take a weight, I assume the code will eventually find it's way back to this point, so I'd need to test after every line of code in 'In Position' that is hasn't been off and done something else (like driving away) that makes that code redundant, wouldn't I?
Just need to clarify my thinking here. Any tips.
Or are there any good articles anyone can recommend that will clarify this, please?
The weighbridge will have 3 sensors.
1- the Front to signify something moving on to the weighbridge
2-Near the other end that shows when the front of the vehicle is far enough forward to be sure it is completely on, and
3-The rear to signify if the vehicle is leaving (or is too far forward if it didn't stop in position)
There are traffic lights in place that I set depending on the position of the vehicle (sensor triggered). However events may not always be triggered in the order I expect and I'm not sure if I'm handling the code correctly.
Here's an example:
1. When the code starts it runs 'Set Weighbridge Normal' - that sets everything to default values, turns on sensor 1 linking to the event handler 'LorryApproaching' and sets the lights green, then waits ...
2. The lorry pulls onto the Weighbride, sensor triggers, code moves to 'LorryApproaching' that turns on Sensor 2 (link to event 'InPosition') and sensor 3 (linked to 'LorryLeaving') and leaves sensor 1 on aswell as you just don't know what some drivers will do!
3. Lorry triggers in position, which in turn tried to identify the lorry, wait till the weighbridge is stable then take a weight.
What if, at this time, the driver doesn't wait and drives on. During 'InPosition' we are now in 'LorryLeaving'. LorryLeaving will know no weight has been taken so will try and get the driver to back up. Hopefully back to retrigger 'In Position' from the start but he could drive off so after timeout the weight is checked and if there's not weight on the weighbridge, it's recorded as potential missed load and we call 'Set Weighbridge Normal'
Here's my concern. It feels like I should be letting the code run through each event to a conclusion so that each can wind back down again till it naturally finds it way back to Set Weighbridge Normal. I'm ultimately calling 'Set Weighbridge Normal' as the result of one or more events that took me out of 'Set Weighbridge Normal' in the first place.
In my old fashioned mind, I see a calling stack getting ever bigger till I run out of memory (sorry, old school programmer here). Is that a real concern of does good old VB.net handle that all for me so I don't need to worry?
If I don't call 'Set Weighbridge Normal' after the vehicle leaves, in the case that sensor 3 was triggered during 'InPosition' when it was trying to take a weight, I assume the code will eventually find it's way back to this point, so I'd need to test after every line of code in 'In Position' that is hasn't been off and done something else (like driving away) that makes that code redundant, wouldn't I?
Just need to clarify my thinking here. Any tips.
Or are there any good articles anyone can recommend that will clarify this, please?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Good deal! Glad to help!
Happy Programming!
-D-
Happy Programming!
-D-
ASKER
Thanks for your response as sorry for my delay replying. I was getting myself confused unnecessarily and I think the task of writing out this question, along with your response allowed me to clear my thinking.
I'm not calling a 'Sub' from inside a 'Sub', I'm calling each sub from within the 'Main' of the Console program (where there's just a console.readline) so when everything has executed, it falls back to there (basically I was worrying about something that wasn't happening).
I did do something that helped simplify it. Each of the sensors was an object in my code that raised an event when triggered. I then had to work out in one block of code (the event handler) all posible situations. That was getting a little compliated so I changed it so that I passed an event handler as a delegate to the obect so that I could more easily control what was happening.
So, instead of something like this:
Dim LeavingSensor as new WeighbridgeSensor
AddHandler LeavingSensor.Triggered, addressof LeavingSensor_Triggered <-- One event handler
I now do something like this:
Dim LeavingSensor as new WeighbridgeSensor
LeavingSensor.StartListeni
Then after the arrival sensor is triggered, something like:
LeavingSensor.StartListeni
That was I can be sure only one event is ever triggered and it's more specific, so easier to code. That combined with a global variable showing the lorry position (set by each event so I can always tell where I am), means I'm now happy with the code and pleased to say it's running and working live now.
And, yes, it is quite a cool project. I'm really enjoying it :)