Jump to content

Uwe Raabe

Members
 View Profile  See their activity

  • Content Count

    2527

  • Joined

  • Last visited

  • Days Won

    145

Posts posted by Uwe Raabe

  1. Posted

    26 minutes ago, ErikT said:

    Often, the only feasible way around using an Application.ProcessMessages call is to use multiple threads.

    It just looks like the easiest to implement, but most of the time it turns out to be the hardest to get it done right.

     

    Another approach is to wrap the code into some TThread.ForceQueue construct. F.i. a loop calling Applicaton.ProcessMessages can be refactored like this:

      

    procedure DoAllTheThings;
begin
  DoSomething;
  while DoWeNeedToWait do
    Application.ProcessMessages;
  DoWhatEverIsNecessary;
end;

    Refactored: 

    procedure DoAllTheThings;
begin
  DoSomething;
  DoTheRest;
end;

procedure DoTheRest;
begin
  if DoWeNeedToWait then
    TThread.ForceQueue(nil, DoTheRest)
  else
    DoWhatEverIsNecessary;
end;

    All the code is still executed in the main thread, but there is no loop blocking anything.

    • Like 1

  2. Posted

    That is just like Application.ProcessMessages works: It processes the messages in the queue. If one of those messages calls Application.ProcessMessages in a loop, the outer Application.ProcessMessages will only get control back when that inner loop ends and the event call returns. 

     

    IMHO, you can safely remove the frivolous in your last statement.

    • Like 1

  3. Posted

    Although it is not written explicitly in the docs

    Quote
    • For a logical operator and a bitwise operator using the same symbol, the logical operator is used only when the operands are booleans. Since the type of record for this record operator is not a boolean, a logical operator will only be used when the other operand is a boolean.

    I assume the Logical operators are used as if they were Bitwise operators when the condition above is not met and no corresponding Bitwise operators are declared.

     

    Nevertheless could you achieve the same using Bitwise operators in the first place.

  6. Posted

    33 minutes ago, Lainkes said:

    But once you disable the panel, nothing can be changed.

    Well, you have to enable all parent controls of the PageControl to let the user change tabs.

     

    In most of the cases disabling a whole form is not what you actually need. Often it boils down to disable individual components unless you can group some with TPanel or TTabSheet. There is no common approach to that as it usually depends on your UI design - which we cannot see.

  8. Posted

    51 minutes ago, jesu said:

    There should be an option to do always a clean compilation.

    Isn't that what Build is for (in contrast to Compile)?

     

    AFAIK, these Internal Errors happens because the compiler doesn't clean up properly. I doubt that this can be fixed by just adding an option to do so. 

    • Like 1

  9. Posted

    That error implies that the underlying field is not existing, probably because the dataset is not open. I would expect that the line  

    DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.DataSource.Edit;

    I added to the code would cause an error first, but perhaps you just missed to copy that line into your code.

     

    Anyway, besides checking for Field <> nil, the question is: Why would you want to set that value when the dataset is not open?

  10. Posted

    It may be better to directly change the underlying data field instead of the control: 

    procedure Tfrm_Page_Control.DBCheckBox44Click(Sender: TObject);
begin
  DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.DataSource.Edit;
  if TDBCheckBox(sender).Checked then
    begin
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Field.AsDateTime := Now;
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Visible := True;
    end
  else
    begin
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Field.Clear;
      DTP_STAT_HAND_GRIF_VOL_DOSSIER_OPVR_DATE.Visible := False;
    end;
end;

     

  11. Posted

    The error message is pretty clear: Set the ShowCheckBox property of the DateTimePicker to True. 

     

    You don't even have to set the Date property to NULL. It should be sufficient to uncheck the Checkbox or set the Checked property to False. That will write a NULL value to the data field instead of 30/12/1899. 

  17. Posted

    54 minutes ago, Ian Branch said:

    but I have just noticed that if I disable a DEFINE, {.DEFINE XXXXX}, the code between the {$IFDEF XXXXX} & {$ENDIF} no longer greys out the code inbetween.

    As this feature is driven by LSP, it looks like the code contains a construct LSP is stumbling about. Do you notice any other problems with Ctrl-Click navigation, error insight or code insight?

  25. Posted

    16 hours ago, Vincent Parrett said:

    You typically do not want the console logger or the xml logggers when using TestInsight - and when running on a CI server you probably don't want the console logger.

    The inclusion of the units seems to do no harm. The linker probably omits them when no instance is created.

     

    It is different with TestInsight as unit TestInsight,DUnitX may not even exist.

×