jwcolby
jwcolby at colbyconsulting.com
Sat Jul 23 10:05:27 CDT 2011
So IOW the readings the engineer takes when he sticks his hand in the light curtain need to be entered in sequential order in the controls? I am way leaning towards a class solution now. I would probably go with a class to hold the control and sink it's events and a parent class with 20 control class variables to hold instances of the control class (assuming that the number of controls (readings) will never change). Each control class raises an event to tell the parent to "step" the sequence. The parent has the stepping code, the control class has the locking / unlocking code. I might even turn the background a different color to visually cue the user. That would also be in the control class. The class would have a method of setting the control enable property. The parent class would load every one of the controls in the (sub) form into a class instance and as they load set all but the first Enable to false. As the Engineer enters the first reading and AfterUpdate fires, the next sequential control (class instance) is enabled, the focus set to that and the current control disabled. Voila, "stepping" enabled controls. Or perhaps instead of enable / disable, use the Locked property. This would allow the user to do something like a double click in the previous control if they made a data entry error, but only immediately. IOW before entering data into the next control Classes would make this whole thing much simpler because all of the code for the manipulation of the control itself would be kept in the control class instead of the form. Further the whole thing "replicates" in each subform simply by instantiating the parent class. The parent class could even load the control classes into the collection. If the order of entering the readings into the controls does not matter, IOW if it is not critical to have reading one entered into control one, then don't worry about it. Just lock the control and allow the user to click in another. But I think the "stepping" paradigm is the cleanest. And of course, as Stuart will point out, you don't have to use classes at all. You could just stuff all of the code in each subform. And enter the nightmare of fixing code in every subform if you find an issue or add a feature. If you are interested I can code this in under an hour. John W. Colby www.ColbyConsulting.com On 7/23/2011 10:40 AM, Arthur Fuller wrote: > Excellent questions, all. > > Here, as briefly as I can make it, is the scenario. There is an object > called a workstation. It may have up to 4 LightCurtains (these devices shoot > beams of light from Right to Left and detect the interruption of said beam > by any object, typically an operator's hand. Upon detection, the machine > must shut down within several milliseconds; a typical measurement would be > 220. The Safety Engineer tests this by inserting his hand into the gap > between sender and receiver, then measures the Shutdown Time. He does this > 20 times. > > Although one would have to be an idiot to record M1 then M17 then M2 then > M20, the current implementation does not prevent this idiocy. > > The measures are taken on a subform. The MaxReading exists on the parent > form. That part I've got already. > > I'm not even sure what I'm looking for here; perhaps basically a defense > against entering M1 then M10 then M11 then M20. Chances are that the user > would not do this, but I feel the need to protect against it. > > Further, there are a maximum of 4 LCs (call them N, S, W, E) and in addition > 4 Two-Handed-Controls (THCs, in the lingo), each of which has up to 20 > Measurements. > > So I'm looking for a clean and elegant way to: > > a) prevent you entering Measure 3 without having entered Measure 2. > b) to grab the value of the most recently entered Measurement and compare it > against the MaxReading so far recorded. > > I have b) solved. a) is another matter, and I have no idea how to handle it, > except perhaps by forcing the focus to the next M# in the AfterUpdate event. > There has got to be something slicker than that, I just know it. > > A. > > On Sat, Jul 23, 2011 at 10:21 AM, jwcolby<jwcolby at colbyconsulting.com>wrote: > >> And further, given that you are working with such numbers of controls I >> would start leaning towards a class solution. Does this need to go into >> multiple forms? If so leaning further toward a class solution. Are the >> controls following a naming convention? Leaning further... >> >> From you original email I got that the user just entered any controls they >> wished, not every control. And you said nothing about multiple forms or >> tabs. >> >> >> John W. Colby >> www.ColbyConsulting.com >> >> On 7/23/2011 10:12 AM, Arthur Fuller wrote: >> >>> 1. Pls forgive me my senior moments, JC. >>> 2. You're such a classy guy, I just knew you'd come up with a set of >>> classes. >>> >>> The problem is perhaps in the UI rather than the logic. So far, there is >>> no >>> prevention upon the user entering M1 then M3 then M20 and leaving all the >>> others out. Granted, this style of data-entry doesn't make sense, but >>> given >>> user-sensibilities (the newly politically correct way to phrase Dumbass >>> MoFo), I need to guard against such ostensibly intelligent responses to my >>> form. I suppose that one possibility is in each AfterUpdate, force the >>> Focus >>> to the next in sequence. >>> >>> All that said, I shall work on implementing your approach. I just imported >>> your code and aside from a couple of vbcrlfs if worked fine. The part I >>> don't like is the specific reference to the active control. I have looked >>> at >>> ActiveControl and maybe that's the path I should follow. I want to >>> compress >>> this into one clean function that receives the currently active control >>> and >>> the currently defined maximum, and then reset the MaxGroupReading to the >>> greater of these two values, so I can copy+paste said "=ComputeMax()" into >>> all 20 of the AfterUpdate events and be done with it. >>> >>> Your last comment (about passing in the form) has immediate potential. In >>> the real case, I have to do this four times, with fields numbered M1..M20, >>> M21..M40, M41...M60 and M61...M80. Each of these lives on a separate tab's >>> subform, but the algorithm remains the same throughout. There may or may >>> not >>> be data on everything beyond M20, as defined by the Parent form. If a >>> WorkStation has only two LightCurtains, then LC1 and LC3 are defined with >>> measures, and the others are not. (Please don't ask me why the sequence >>> goes >>> LC1, LC3, LC2 and LC4 -- I'm just a grunt programmer in the trenches, not >>> a >>> certified P.Eng). I just do what I'm told... which argument didn't work at >>> Nuremberg and perhaps won't pass in Toronto, but that's my argument and >>> I'm >>> sticking to it. >>> >>> A. >>> >>> On Sat, Jul 23, 2011 at 9:46 AM, jwcolby<jwcolby@**colbyconsulting.com<jwcolby at colbyconsulting.com> >>>> wrote: >>> >>> Bubble sort? >>>> >>>> Arthur!!! >>>> >>>> I think a set of classes... ;) >>>> >>>> Actually a simple function where you pass the control with the data just >>>> entered and the MaxReading control. The function compares the value just >>>> entered with max reading and sets maxreading to the new value if the new >>>> value is bigger. >>>> >>>> function SetMaxReading(ctlJustEntered as control, ctlMaxReading as >>>> control) >>>> >>>> if ctlJustEntered.Value> ctlMaxReading.value then >>>> ctlMaxReading.value = ctlJustEntered.Value >>>> endif >>>> end function >>>> >>>> If you need to set dirty false then pass in the form as well. >>>> >>>> John W. Colby >>>> www.ColbyConsulting.com >>>> >>>> >>>> >>>> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> >> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >>