Recent

Author Topic: How to determine difference with TrackBar onChange neatly.?  (Read 911 times)

jamie

  • Hero Member
  • *****
  • Posts: 6090
consider this
Code: Pascal  [Select][+][-]
  1. Procedure Tform1.TrackBar1Change(Sender:TObject);
  2. Begin
  3.   With TrackBar1(Sender) do Position := Position+1;
  4. End;
  5.  

 In an app where you need to move the slider one or more notches ahead or behind from where the user selected.

 In this case the slider is on a automated trigger from remote IO and at least up to 10 at one time, it may change depending on the setup.

 These sliders move always during operation and the user has the option of setting them back or ahead.

 with each move the values are also written back to the controller and only the user values are wanted, the automated trigger does not execute this method block it only uses the Position property and only shows visual update on the screen..

 I moved an app from D3 that works perfectly there, fails here and also it seems Current Delphi also fails in the same way.

 without ugly looking hacked code, please tell me how to manage this? Also please don't consider using the TAG property because that is already in use, that is how I identify the controls with the remote controller. Currently it just sets the slider to max on a single click.

 I have other controls that gets updated from the remote IO too, but we'll cross that bridge when we get there.

The only true wisdom is knowing you know nothing

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: How to determine difference with TrackBar onChange neatly.?
« Reply #1 on: May 16, 2021, 01:18:42 pm »
Changing Position will triger OnChange again. Break the cycle with a writable constant or form variable. For instance:
Code: Pascal  [Select][+][-]
  1. procedure TForm1.TrackBar1Change(Sender: TObject);
  2. const
  3. {$push}{$WriteableConst ON}
  4.   Busy:boolean=False;
  5. {$pop}
  6. begin
  7.   if Busy then exit;
  8.  
  9.   With TTrackBar(Sender) do
  10.   begin
  11.     Busy := True;
  12.     Position:=Position+1;
  13.     Busy := False;
  14.   end;
  15. end;

Edit:
Notice that WritableConst is on by default.
« Last Edit: May 16, 2021, 01:21:58 pm by engkin »

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: How to determine difference with TrackBar onChange neatly.?
« Reply #2 on: May 16, 2021, 05:43:26 pm »
That won't due because this code accepts all controls in a single event and there is threaded events, the check point value must reside within the current instance that is being called.

That method there will block other calls with different controls in threaded models or if I call the application process messages.

 For the time being I can create a cheater class at the top of the source and add a MODIFIED property which will be unique to the calling instance.. This is still ugly, it should be in the class code. I suppose I can recompile local copy of LAZ to fix this but I don't like depending on special builds.

The only true wisdom is knowing you know nothing

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: How to determine difference with TrackBar onChange neatly.?
« Reply #3 on: May 16, 2021, 07:06:56 pm »
Instead of that simple boolean constant, you can use TFPList. Add it to the form and take care of its creation and destruction. The previous procedure becomes:
Code: Pascal  [Select][+][-]
  1. procedure TForm1.TrackBar1Change(Sender: TObject);
  2. var
  3.   TrackBar: TTrackBar absolute Sender;
  4.   i: Integer;
  5. begin
  6.   if Modified.IndexOf(TrackBar)>=0 then exit;
  7.   i := Modified.Add(TrackBar);
  8.  
  9.   TrackBar.Position:=TrackBar.Position+1;
  10.  
  11.   Modified.Delete(i);
  12. end;

The GUI controls are not touched by any thread other than the main thread. What do you mean by "threaded models"?

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: How to determine difference with TrackBar onChange neatly.?
« Reply #4 on: May 16, 2021, 07:55:56 pm »
Quote
The GUI controls are not touched by any thread other than the main thread. What do you mean by "threaded models"?
I have threads running in the background that sets bit flags in memory and I have a service loop much like the Application.ProcessMessages but only services the thread pool messages. That in turn calls all GUI active items that matches the TAG id..
 
 Problem is that in some change events there could be a slight sang in performance for a moment and to avoid the data loss I call this service loop during a onChange event at times of various controls. This all works well and only the controls that are not being serviced at the time will get a chance to call their events.. This is why its important to have the control have their own safeguards built in per instance.

 But the real issue here is you need to way to determine user changes over software changes because otherwise a user change means it needs to transmit back to the remote IO for updates but if all we are doing is rebroadcasting the same info that just got sent, it ties up the communications line and causes network lag, this is how I detected this due to slow network response when things got busy and this never happen when the code was compiled on early Delphi editions. But It also happens with Lazarus..

The only true wisdom is knowing you know nothing

 

TinyPortal © 2005-2018