Khorkhe

Apologies, I made a mistake. I was intending to refer to the Equal operator (and NotEqual), where the docs below say: Equal(a: type; b: type) : Boolean; yet in the screenshots initially posted, EntityDAC apparently uses record operator overloading, to implement a compile-time checked SQL Builder that generates SQL strings. However in this case, the Equal operator overload will return a string, that is: Result := aLeftOperand + ' = ' + aRightOperand This compiles and runs fine as per the screenshots above (and as per EntityDAC's components), but the documentation says it must return a boolean. https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Operator_Overloading_(Delphi)

Hello, When overloading operators in a Delphi record, it is possible to specify a result type that the documentation does not recognize: TCondRec = record public Text: string; Params: TParams; class operator LogicalAnd (aLeft, aRight: TCondRec): TCondRec; // return TCondRec instead of Boolean class operator LogicalOr (aLeft, aRight: TCondRec): TCondRec; // here as well This allows us to write expressions such as the below, to generate an SQL string as the result of joining `aLeft` and `aRight` with an `AND` or `OR` operator. It seems this technique is internally used by EntityDAC components in order to provide an "SQL Builder", somewhat similar to the idea exposed here. My worry however, is that this syntax showed above is not documented: according to the Embarcadero docs, these class operators are supposed to return a Boolean. Here's some screenshots of what can be done: The question is: How concerned should I be about using such a library, in the eventuality that Embarcadero decides to enforce the syntax described by its documentation? Or alternatively (if lucky), any chance the documentation itself is wrong? (docs are often known to be missing, maybe they just didn't write it correctly here?) Thanks

@Stefan Glienke out of curiosity, why is System.JSON a no-go, and what alternatives might you recommend? Thanks!

@Uwe Raabe found two main form entries, no clue how that could have happened, possibly the compiler migration? Cleaned it up in any case. this is a project started on XE7, which I've taken to 10.3 (no copy, just compile as is). Uninstalled all addons (MMX, CNPack, GExperts) to isolate the problem. It also seems I have located the culprit to be the "background compilation" option. Had it enabled since XE7 due to large cycles / long compilation, which have since gone down drastically to a point where the background compilation is no longer really needed. This is reproducible on a fresh 10.3.1 project, maybe add a button and an OnClick event. the current steps to reproduce: - have background compilation on - full build, just in case - build passes successfully - introduce syntax error, don't save - compile without saving - compilation passes successfully (incorrect behavior) to fix: - disable background compilation - remove syntax error - save and full build, just in case - compilation passes successfully - introduce syntax error, don't save - compile without saving - compilation fails (correct behavior)

ah apologies for the misunderstanding. here it is: PBXAlert - Copy.rar

I'll give it a shot but if you check previously attached screenshot, the project search path is empty, and there's one dcu in the unit output directory.

already did, they are the two screenshots in my previous post.

@Uwe Raabe the unit is explicitly mentioned in the project. Some good news! I was able to reproduce the issue on a very small project (single unit) where all the big project specific details do not apply, see the info below and screenshot attached: - in the code: the syntax error is visible, unsaved. - top left: IDE detects the error - project options: all defaults, no search paths - messages: compilation success (same as popup window) - windows explorer: exe and dcu have different timestamps, off by one minute: the exe was re-created on the second compilation, but the DCU was ignored. to top it off, second screenshot shows the code saved, yet the problem persists. not sure what to make of this. I do have a batch script that can delete all my generated outputs, full clean and rebuild, but this is not practical at all. when to trust that the compiler did its job correctly?

Did the following: - went over the search paths thoroughly, removed everything that was not necessary (sources of the current project, bins of required libraries). - deleted the existing .dproj, let Delphi auto-create one - did a global search made sure there is one and only one version of my sources on the PC Still ignores unsaved pas. Worth noting that the project is not small. Tried reproducing the issue on a fresh blank project but failed to do so.

Hello, I'm encountering a problem with Delphi 10.3.1, which seems to show up nowhere on the forums so far: migrated a project from Delphi XE7 which was working fine for several years. in 10.3.1, the compiler is ignoring changes I make to a regular unit (.pas) of a VCL exe. Even adding a blatant syntax error (which shows a red entry in the IDE error list), when compiled, gets completely ignored, and the compilation succeeds. The DCU for this unit is re-timestamped, with what seems to be the source prior to the modification. the issue seems to be fixed (though not confirmed 100%) by enabling the "save upon compile or build" option. when saved, the updated content of the .pas seems to make its way into the dcu, and breakpoints can be set again, to match the new PAS content (instead of being offset to match the previous code). There are no duplicate unit names in the project, and a rebuild does not necessarily fix the issue. Has anyone else encountered this problem? I would like to see if this is only occurring at my site (i.e. project related) or if this is a known issue, with a bug filed for it. Thanks a lot!