Jump to content

Lars Fosdal

Administrators
  • Content Count

    3524
  • Joined

  • Last visited

  • Days Won

    116

Posts posted by Lars Fosdal


  1.  
     
     
    19 hours ago, dummzeuch said:

    If there are multiple instances of program1 and it always uses the same file name when it starts its own instance of program2. These multiple instances would then all write to the same file.

    That's a race condition in my opinion.

    I'd call that a concurrency issue, rather than a race condition?

    SharedFileName := '%temp%\MyFileName.ext.' + GetCurrentProcessId.ToString;


  2. 10 hours ago, Dmitry Arefiev said:

    We have two problems:

    1) REST, DBX, System.JSON duplicating JSON serialization classes.

    2) Non complete docu for (1) classes.

     

    We want to keep only System.JSON with options for backward compatibility with REST, DBX. And only to develop System.JSON. When this will happen, then all demos, tests (internal), docu, must be updated to reflect the current RTL state. Now it is not the time for docu work ...

    If you don't document it - how do you expect to maintain backward compatibility?


    My code relies on REST.Json 

    - ObjectInstance := TJson.JsonToObject<T>(aJsonString) ;

    - aJsonString := TJson.ObjectToJsonString(ObjectInstance,  [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601]);

    - TJSONInterceptor / JsonReflectAttribute for instructing the converter to drop TDateTime properties that have 0 as value.


    What are the equivalents in System.Json ?

     

    • Like 1

  3. I wish the various Json classes were better documented.  http://docwiki.embarcadero.com/Libraries/Rio/en/REST.JsonReflect is particularly poorly documented with regards to marshalling, interceptors and converters.

    I have long been wondering if the TJson.JsonToObject<T>(aJsonString) can be made to handle mixed type arrays {"list": [5, "text", {"prop": "value"}]} by injecting converters, but it seems impossible - but then again - the above mentioned tools are undocumented.

    • Like 1

  4.  
     
     
    On 6/5/2019 at 11:45 AM, Mike Torrettinni said:

    So, a question for you: I assume you would use 'Do not show message when creating files' checkbox, when it first pops-up, knowing you can access any report file through another way, like 'View all created files' option?

    Yes, that could work well, IMO.

    • Thanks 1

  5. I'd make a generic "application log" where I would log the different actions, and for each action type - offer the possible options when viewing the log.
    Whenever something is logged, I'd have a "New Item" counter (Think "number of unread") somewhere in the UI - f.x. on a button that opens the log.

     

    I also strongly dislike modal dialogs, but when I need that file, I do need a mechanism to find it.

    • Like 1

  6. This works well in our 10.3 production code, so it is not entirely useless.  The THardAllocList is a TList<T>, though - not a TArray<T>.

    Several typeless inline declarations with initialization, and a inline string var with initalization.

    procedure TPSDTask_ImportCustomerOrders.ProcessHardAllocations(const aDeliveryId: Integer;
      const HardAllocations: THardAllocList);
    begin
      for var Alloc in HardAllocations
      do begin
        var TPack := GlobalTPackList.FindByTPackNo(Alloc.TPackNo, True, True);
        if Assigned(TPack)
        then begin
          var TPQ := TPack.GetQuantityOfArticleOnTPack(Alloc.ArticleId);
          var ArtSum := GlobalArticleSummaryList.FindByArticleId(Alloc.ArticleId);
          if ArtSum.QuantitiesAreEqual(Alloc.Quantity, TPQ)
          then begin
            if TPack.AllocatedDeliveryId = 0
            then begin // Allokér TPack til leveranse
              var AllocMsg: string := '';
              if TPack.AllocateToDelivery(aDeliveryId, AllocMsg, True) = rOK

  7. 1 hour ago, David Heffernan said:

    Stepping through execution in an interactive debugger is fine for some debugging tasks, but it's just one form of debugging. It's hopeless for debugging threading specific issues. It's the wrong tool. Lots more to debugging than interactive debugger step through. 

    I use extensive logging, so that does clarify most of my threading issues - but sometimes, you simply need to get into the structures to understand where shit happens.  At that point, I'd like my debugger to be well behaved.  Unfortunately, it is not.


  8. I am quite fond of class variables of the Class of TSomeClass type.

    I use these for polymorph creation of class instance variables, typically handlers of some sort, but C# does AFAIK not have a similar construct, i.e. type as a variable.

     

    What are the best practice alternatives to using class variables?

    Am I limited to case / if then else factories or is there something more elegant around?


  9. On 4/29/2019 at 4:55 PM, Jacek Laskowski said:

    You can freeze all threads except the debug thread (in Threads window).

    Since it often is the actual thread interaction in a multithreaded server that is the cause for debugging - freezing other threads would be undesirable.

    I'd settle for a way to have breakpoints thread context aware so that I can choose to have breakpoints active in specific threads.  A way to easily enable/disable breakpoints per active thread context.

×