Mike Torrettinni

I'm analyzing a log file full of sql scripts of I'm trying to come up with a some sort of summary view that would show what kind of scripts are in the log.

A simple example:

select fname, lname, city, zip, taxcategory, taxowed from taxcustomers where taxcategory = 'TXX-01' and taxowed>0

select fname, lname, city, zip, taxcategory, taxowed from taxcustomers where taxcategory = 'NL-xxxx' and taxowed>500

and 100s+ of same scripts with different values in taxcategory and taxowed fields. So, I would like to end with something like this:

SQL script: select fname, lname, city, zip, taxcategory, taxowed from taxcustomers where taxcategory = '?' and taxowed>?

Column: taxcategory, values: ['TXX-01', 'NL-xxxx' , ... ]

Column: taxowed, values: [0, 500 , ... ]

Any suggestions how to approach this? Any such string utilities already exist, commercial perhaps?

3 hours ago, TLG said:

It has been working for over a year.

There's probably many reasons why it suddenly doesn't work, in previous versions of Delphi when this happened to me it helped just to re-set the icons. So, clear icons to produce default Delphi icons, re-start IDE and set new icons. This usually worked for me, perhaps will for you. too.

6 minutes ago, david_navigator said:

Crafty 🙂

Perhaps a check if total strings lengths are equal, before constructing actual strings. Calculating lengths is usually faster then concatenating strings. Could save some time.

Not sure if this makes any difference, but if I access site from US I get partial results, some show up some have error. Using VPN from other countries works 99%, rarely, but every now and then the error shows up.

24 minutes ago, Uwe Raabe said:

Indeed there is. That has probably been the trigger to revamp the old style guide to support the newer language features and establish it inside the developer team at Embarcadero. I hope we can expect more consistency here in the future.

 

That doesn't invalidate the argument, though. The standard style is widely spread and most developers are quite proficient to read it. A lot of style guides in the wild are more or less small variations (if at all) of this standard. You won't ever surprise any developer presented with sources following this style. That somehow makes it unique and means it has an advantage.

Well, it is true that I'm still looking at 10.2 sources, so perhaps 11 or future versions will improve, but I seriously doubt they will put resources into restyling current code over bug fixes. I hope not.

5 minutes ago, toms said:

I would stick to the notation of the Delphi sources rather than using others.

There's quite a lot of inconsistency in Delphi sources, in some cases very obvious when a different developer implemented a change and introduced new variables. Completely different style, or usage of L prefix.

7 minutes ago, Anders Melander said:

I'll be happy to sell you a copy.

Well, just don't buy it in the first place. There's always a preview of some sort so you know what you are buying.

If I were you, I wouldn't worry too much about it, I doubt he will finalize it to sell it. If our ghost buster got under his skin, he probably can't stomach the English proofreading, anyway.

Very impressive that a full book can be written on this topic!

It was quite easy to read, although could use some more incorrect vs correct examples, some points could be easier demonstrated like this and not trying to explain with text. All in all not boring book, considering the boring topic.

But the examples just reconfirmed how awful F, L and A prefixes look. I use f, v (local vars) and x (unit vars)  and a.

On 2/19/2022 at 12:59 PM, Dany Marmur said:

function Name(const AArgument: TType); // Ouch!

function Name(const aArgument: TType); // Yeah!!!

I agree with this 100%.

It was a bit confusing to read that L prefix for local variables is encouraged, and not a guide: "The “L” prefix is encouraged for local variables in case identical names would conflict or shadow identifiers of parameters, variables, fields, or property names."

When a style guide is encouraged to be used, it's not a guide but a free-for-all.

Too bad he left and deleted the account. I would buy the book, if it was sold.

40 minutes ago, Ian Branch said:

In the new structure

Then you can make them as fields of this new structure.

If these variables are local to unit (defined in implementation) than leave them, if you really need to, but with such a small number of vars this is good opportunity to practice removing/converting global vars.

1 hour ago, Ian Branch said:

var APJobTickets: TnlhTable; 
   SendAPMsg: TnlhQuery;
   dsSendAPMsg: TDataSource;

 

I assume these are global variables accessed from MainForm, right? If only used in MainForm, then don't use them as globals but define them as MainForm fields and pass them as parameters to the method:

MainForm: TMainForm
...
private
  fAPJobtickets
  fSendAPMsg
  fdsSendAPMSG

// then on some action (button click, form create...) create them like this:
CreateApDataComponents(fAPJobtickets, fSendAPMsg, fdsSendAPMSG);

there are multiple ways to implement this, but this is simple example that will then allow you to expand, change.... try to avoid global vars.

Also, make sure the new unit doesn't use MainForm unit - avoid circular reference, if possible.

17 minutes ago, Ian Branch said:

This meant referencing the MainForm components in the procedure with the TMainForm. prefix.

I then Copied the entire routine and all the Uses, Var and Const clauses over as well into a new Unit just to make sure there were no initial issues.

Then there were the components on the MainForm that were being referenced.  e.g. tables, queries, dialogs, etc, which needed to be created.  I could have left them in the MainForm and just left the TMainForm. references but I don't believe that is the right way to go.  I am open to advice/opinions on this.

I created the tables and queries in code, all good.

I now have to create the remaining MainForm components, dialogs, etc, in code and it should all be good.

Can you show very simple example what you did here, for 1 control what was before and how it is now? I don't understand why you are recreating controls... the originals were part of MainForm, right?

I just want to make sure my suggestion didn't lead you down the wrong path.

Thanks, I can't believe I tolerated these annoying useless .dfm changes for so long!

18 hours ago, Ian Branch said:

procedure TMainForm.SendAPEmails(Sender: TObject);

I refactored 100s of methods like this, from within forms, in past few years, and the first thing I do is to make it independent of form and controls. So, remove form reference to become:

procedure SendAPEmails(parameters...);

also move the declaration out of the form, but keep in the same unit.

Now make it work without reference to the form or controls. You will probably need to set parameters to pass values to assign to controls.

Once it works as a standalone method, move it to new unit. You will see what uses clause you need to define to work. Perhaps you will need to move a few more methods that are used just by this method.

Do the same for other print routines. Once you move a few or all of them, then it will be easier to see what patterns of code are repeated so you can refactor to smaller methods.

I found this was best for my case, trying to refactor in the form unit with lots of other code was quickly becoming unmanageable mess. But if you have these methods in smaller unit(s) the refactoring is much easier and more obvious.

On 11/26/2021 at 9:35 AM, timfrost said:

For Windows, MiTeC System Information Component Suite can get every hardware and software detail you can think of, and more; there is also a trial version available. https://www.mitec.cz/msics.html

Thanks, it looks like it does cover a lot. And having available all the demos is quite refreshing. No Linux support is not a deal breaker, but it would be nice to have all in one.

On 11/26/2021 at 12:21 PM, shineworld said:

You can get any info with WMI support.

WMI covers a very very incredible set of infos.

Thanks, at this moment I'm looking for ready-made library (commercial) up to date and a Linux support is a plus.

There's plenty example available online for all sorts of system info, but I'm trying to avoid my own trial and error.

In my projects, I don't gather user identifiable info, even for licensing. Worked good so far, but now I have the need for different licensing style.

I have methods to get user name, computer name, some hardware info, local IP... for Windows. But I'm looking also for Linux version. Also identifying if VM is used or not.

So, looking for a library (linux would be a plus) that handles also cases like VM, RDP, Citrix, roaming user profile management... and other network particulars that can give odd results with basic methods.

Any suggestions?

9 minutes ago, Bill Meyer said:

OneDrive? Don't get me started.

No improvement in W11?

I thought that was such a cool idea, shared office files, but I switched it off very quickly, on W10. Unreliable, kept complaining it's offline and can't connect. Shame.

OK, first test done successful! 🙂

Things are much clearer now!

This video is for real beginners, very easy to follow:

Thanks for the help everybody!

2 minutes ago, Attila Kovacs said:

who gives you the guarantee that the second call is returning the same value? <o>?

I guess it can change, yes, but it my example it doesn't. But you are right, it's not guaranteed. Still, maybe it can detect if the called method can return different result... if not, then it's the same call.

Can we expect future Delphi compiler be so smart to detect repeated calls and just do the once, like:

if (CustomerNet(C) = 0) and CustomerIsNotActive(C) or 
   (CustomerNet(C) > 0) then
    

To avoid 2 calls, I can add variable and store CustomerNet(c) and use it in the condition, but wouldn't it be cool for compiler to detect such cases on its own and optimize so that just 1 call gets executed?

Are other compilers smarter than Delphi and can handle such cases better?

From all the blogs I read, I didn't come across anything like such a simple explanation.

So, it's more like: start with test cases that produce exact results as expected, then slowly expand to test for most commonly expected 'wrong' input. Stop when it makes sense.

Just now, Lars Fosdal said:

It would be natural that the test cases also contain negative tests - i.e. stuff that is supposed to fail. 

Only testing happy path = recipe for disaster. You want to know that if you get garbage in, at least your code can recognize that it is garbage, report the problem, and move on.

OK, this makes better sense.

Because testing Calc examples of x+y makes sense to test -MaxInt.. 0,1..MaxInt examples. With string or lines of string... it's 'unlimited' possibilities.

4 hours ago, Fr0sT.Brutal said:

External data sets (files with test data and expected results)

Not sure if what you are referring here is same as I do now, but I have 'test cases' where I have exact input and output as text files. I run test with previous and current build and compare results (text files) if new build changed anything. Tests like these makes sense.

So, I'm having hard time going from such test to this:

6 hours ago, Lars Fosdal said:

Many of the tests are there to verify that we f.x. have working FromString/ToString methods for all our enumerated types,

I understand we have to test almost every method we have, but Calc and it's family of tests have limited input. How do you test parsing a line from text file?

For example, if text line is expected to be in this format: A B C D or A B1, B2 C D. You can test for a few examples for parser to parse correctly and identify A B C and D parts.

But if you define test case for these 2 examples, what's the point of test case, it already works.

1 hour ago, Vincent Parrett said:

DUnitX isn't an extreme version

What does X stand for?

1 minute ago, Bill Meyer said:

Have you looked at this? https://delphiprogrammingdiary.blogspot.com/2018/09/unit-testing-by-using-dunit-in-delphi.html

 

DUnit was the first unit test base for Delphi. DUnitX came later, and I think you will find the articles on DUnit are a simpler starting point than those for DUnitX. Nothing wrong with DUnitX, it's just that many writers will likely assume you already use DUnit.

Thanks, I saw that blog, but it uses similar Calc example. I'm having the same problem with such examples like when I was learning about classes and I found plenty examples with animals, TAnimal, TDog, TCat.

I guess my imaginations is not good enough to go from test case of x+y to real life example, like file parser.

I don't need extreme version, yet, so DUnit is just fine for me. I found the one short chapter on unit testing in Expert Delphi book, by Pavel Glovacki, no other books on this topic, for Delphi.