david berneda

😂 I can quickly identify code not written by me when I see a minor formatting difference. Even 20 years later 😂

Manual formatting for me is the best way to make sure the code is well done, calmly, as a final double-check there are no big bugs or something missing. I'd never do auto format, a headache to configure the many ways format can be done.

CPascal is another approach, it calls and generates LLVM from Pascal code. Ternary conditional is done C-style using "?" https://github.com/tinyBigGAMES/CPascal

If it can be of any help, case/switch In my "pet language" allows expressions at each case item. I choose the reserved keyword "when" just for fun, it can be another keyword in one second. https://github.com/davidberneda/Vidi // When. Multiple "ifs" (switch, case) num ::= 5 Console.PutLine(num) when num { < 3 { num:=123 } 4 { num:=456 } // is num equal to 4? <>6 { Console.PutLine('num is not six') } // otherwise else { num *= 7 - 1 } } Console.PutLine(num) // Works with any type when Name { "Jane" { Console.PutLine('Name is Jane') } "Peter" { Console.PutLine('Name is Peter') } // .Length=3 {} // TODO, use members "." } B : Text := 'b' when 'a'+B { "ab" { Console.PutLine('Text ab') } }

Do you think on using it? It can be useful to people that like to do debug logs.

Before submitting a jira request ticket, do you think is this a good/useful idea: file: project1.dpr {$PASS -$R+ -DFOO} program Project1; ... dcc32.exe project1.dpr the compiler starts looking at project1, finds the PASS option and then this is like: dcc32.exe project1.dpr -$R+ -DFOO project wide, to force compiler options that work like if these were in project options. I had an issue with a test project that lost the options, this would never happened if something like PASS existed.

Yep ! But this is exactly what I was trying to avoid, an inc file that would need to be copied and duplicated because not all units belong to the same projects or products, there is no shared path where to put that inc.

The PASS should only be allowed before reserved words program and library. Its just like if you were passing the params at the command line, before parsing anything. Several compiler params cannot be used inside an inc file. PASS allows everything. Units will still work right they do now, no changes.

And maybe the project uses units from different projects, folders, that do not share a common place where I can have my single unique inc file, thus needing multiple duplicate identical inc files, a nightmare to maintain.

But if I have 100 units I need to include the inc in the all 100 of them. This avoids that.

Hi all ! Do you know if there is some global variable in the RTL that can be used to "register" a class or something? Or some neat trick? 😂 The need is, unit A needs to "talk" to unit B, but they cannot use them, and cannot use any unit C that could act as a common base. Main reason is A and B are units that form part of completely different products, different packages that cannot depend between them. Firemonkey has a nice "service" global registration via interfaces, I'm asking about the same concept in the RTL. regards ! david

Yes, I need a general mechanism to primarily allow embedding controls (vcl and fmx) into for example a tabsheet, like hooking when a form shows, it calls an event and that results in a new tab filled with stuff. No problem at all to do this when units are used in a traditional way. I've been doing that for 30 years now since D3 😆 The wish is to be able to do the same without units dependency, nor a common base unit or a common required package. This way users can install a product/packages/sources, and after that maybe install another product/packages/sources, and suddenly this new product dialogs appear at the first product.

Yes the same vcl dialogs can be used outside the ide at runtime, and there are also fmx equivalent dialogs, with the same need and purpose.

Grok also suggest using TMessageManager and provides this example code: unit UnitA; interface uses System.Messaging; procedure SendMyValue(const Value: Integer); implementation procedure SendMyValue(const Value: Integer); begin TMessageManager.DefaultManager.SendMessage(nil, TMessage<Integer>.Create(Value)); end; end. unit UnitB; interface uses System.Messaging; procedure StartListening; implementation var SubscriptionID: Integer; procedure MyHandler(const Sender: TObject; const M: TMessage); begin if M is TMessage<Integer> then begin ShowMessage('Value: ' + IntToStr(TMessage<Integer>(M).Value)); end; end; procedure StartListening; begin SubscriptionID := TMessageManager.DefaultManager.SubscribeToMessage(TMessage<Integer>, MyHandler); end; procedure StopListening; begin TMessageManager.DefaultManager.Unsubscribe(TMessage<Integer>, SubscriptionID); end; end. So, hope it works with more elaborated types instead of Integer (ie, TObject etc) There are many useful applications of this mechanism, with no dependencies. Specially 3rd parties can interact each other without the need of "requiring" each other packages, which is a versionitis nightmare. We could add some layer on top of this to make it easier and standard.

The instance can be for example a simple component, and casting one of its children components in a safe way, ie: "as xxx". The global thing I'm after is, ideally a TObjectDictionary<String> where any unit can add its own object and other units can query and obtain it using for example a string key. This would work across packages, design and runtime, vcl / fmx, everywhere. initialization // unit B Globals.Add('MyKey', MyObject); // unit A if Globals.Exist('MyKey') then ... Then the issue is to cast the object to well known existing types to avoid the potential crash you describe. In my particular need, one unit "A" shows a dialog and looks for a global control that maybe another unit "B" has created. If that control exists, it is used in dialog A. So A and B don't know and don't use each other directly or indirectly, but the end result is for example a tabsheet created in B is displayed in A.

The instance can be for example a simple component, and casting one of its children components in a safe way, ie: "as xxx". The global thing I'm after is, ideally a TObjectDictionary<String> where any unit can add its own object and other units can query and obtain it using for example a string key. This would work across packages, design and runtime, vcl / fmx, everywhere. initialization // unit B Globals.Add('MyKey', MyObject); // unit A if Globals.Exist('MyKey') then ... Then the issue is to cast the object to well known existing types to avoid the potential crash you describe. In my particular need, one unit "A" shows a dialog and looks for a global control that maybe another unit "B" has created. If that control exists, it is used in dialog A. So A and B don't know and don't use each other directly or indirectly, but the end result is for example a tabsheet created in B is displayed in A.

Ah ! That's exactly what I'd like to avoid, a shared package. Potential versionitis issues if A and B where compiled with a different version of the shared unit/package. Source code is not always available to recompile.

Yep ! but I need a cross platform vcl / fmx way. TMessageManager is ideal and works since XE3 2012 Hope it works !

Thanks for your help Remy ! In the same process (the ide at designtime). RegisterClass is not enough because both units should share a living instance. TMessageManager can be maybe a good solution, first unit listens and second unit asks, passing an integer address of an instance, then both units can cast it to a class. I'll try this !

https://medium.com/@Steema/visualizing-subsurface-data-with-precision-softdrill-and-teechart-integration-7f64cf871fc6 1_K2zv9GfsGDnX6lfv5FSI3g.webp

BIGrid2.Data := TGridify.From(BIGrid1.Data, 'Happiness', 'Year', 'Person') https://github.com/Steema/TeeBI/tree/master/demos/delphi/vcl/Grid/Gridify

Example sources: https://github.com/Steema/TeeGrid-VCL-FMX-Samples/tree/master/demos/FireMonkey/Database/Master_Detail_FireDAC TeeGrid can be easily programmed to display unlimited sub-grid levels. Just add an "expander" render to enable "+" and "-" clicks, and set an event to obtain your desired sub-rows. uses Tee.Renders; var Expander : TExpanderRender; Expander:=TeeGrid1.Grid.Current.NewExpander;

TDataItem class is just four units, no dependencies, 100% Pascal code. It can be used standalone from TeeBI. uses BI.DataItem; var MyData := TDataItem.Create https://github.com/Steema/TeeBI

Comprehensive list of TeeGrid features: https://github.com/Steema/TeeGrid-VCL-FMX-Samples/wiki/3.-Getting-Started TeeGrid is free for non-commercial use.

https://github.com/Steema/TeeBI/blob/master/demos/experiments/bigdata/OneBillion/readme.md This demo shows TeeBI capabilities with big quantities of data, rows and cells. It first creates a default dummy database of One Billion cells (thousand millions). Data is saved to a disk file in your TEMP folder: "big_data.bi" (4.5GB) in aprox 4 seconds. Once data has been created it can be loaded again from disk in aprox 2.5 seconds. The "Query and Visualize" form uses this big data to do some visualizations. (Queries traversing so many millions of rows are not immediate, of course !) But you can run them in a normal laptop. // Sum the amount of Sales year by year, all rows: BIQuery1.Measures.Add(BigData['Sales']['Total'], TAggregate.Sum); BIQuery1.Dimensions.Add(BigData['Sales']['Date']).DatePart := TDateTimePart.Year; BIComposer1.Data := BIQuery1.Calculate;