Tommi Prami

Hello, I was pondering folowin situation, where there are easily quite many repeating code lines, and how to make int onew liner. var var LField1: TField; LField2: TField; LField3: TField; LField4: TField; begin LField1 := Query.FieldByName('FIELD1'); LField2 := Query.FieldByName('FIELD1'); LField3 := Query.FieldByName('FIELD1'); LField4 := Query.FieldByName('FIELD1'); // ... // Should be nice to have it like this InitField(Query, [LField1, LField2, LField3, LField4], ['FIELD1', 'FIELD2', 'FIELD3', 'FIELD4', ]); It would be easy to make local procedure, case by case with var parameters etc, but that would not be very elegant. What I mean by dynamic, is that it would handle any number of fields and field names, oas long as there are same number of them passed to the procedure.. Other case would be that could pass local variables and the routine would create those objects for me on single line.

True, Calculating the sum was just placeholder of some calculation going on in the loop But very true, if can get sum forehand, would be smart to get it. -Tee-

As Uwe explained...

Depends of number of calls and fields. If 8 field 50 places, it would be from 400 -> 50 lines of code. I think it would be significant, Would be net win after first one. And would make the procedure way more clean, without initialization code in it.

Does not work, know because I've tried that approach in the past, and retried your code and it does nothing. (outside of procedure, which is the important part), // usage var Field1, Field2, Field3, Field4: TField; begin Field1 := nil; // ... Field2, Field3, Field4 ConnectFields(Query, [ Field1, Field2, Field3, Field4], ['Field1', 'Field2', 'Field3', 'Field4']); // Fields star as they are in here, nil or not nil, doesnt matter... But eassy to check by nilling the fields becore and after call. Other problem in this tat compiler starts to complain about Fields are uninitialized. But that is separate issue...

Nice could be done something like that,. but field names are not indexed, usually and after that it is just the same as the my original example I am trying to solve... But Not looking for workaround... -Tee-

Yes... But totally different thing... And would have exact same problem. Would need to initialize variables for indexes by name. Constant magic number indexes leads to buggy code. I am looking for solution for getting fields, and also solution for other cases I could adapt it to. Getting fields is just one use case of this type of procedure I would like to use... -Tee-

var LTotal: Double; LField1: TField; LField2: TField; LField3: TField; LField4: TField; begin LField1 := Query.FieldByName('FIELD1'); LField2 := Query.FieldByName('FIELD1'); LField3 := Query.FieldByName('FIELD1'); LField4 := Query.FieldByName('FIELD1'); Query.First; while not Query.Eof do begin LTotal := LTotal + LField1.AsFloat; // More stuff done with local field variables... Query.Next; end; In this case, TDataSet and TField are RTL stuff or their descendants... So implementation should be kind that works if I have no control over the API of the class.. -Tee-

In this case I get the field usually when they are needed in the loop, or get rid of with-clause or something like that.

Even something like 1.5 pass compiler that would enable some functionality or extend existing would be cool to have... -Tee-

This would be good start. People in any teams have different level of eyesight. Different scaling needs etc. This should have been implemented from the start the way that values in dfm would have been normalized to 96 as default dpi. Or something like that. Sure there could have been rounding errors, most likely.

Seems that my problem is not affecting all then... -Tee-

Can someone build release version of GExperts with patched D12, with current sources? If can, could you share it for testing.

Please all vote for this. Vote seems up still... -Tee-

Updated D12, did not check is this 12.1 or 12.0 Fix1 But update is installed. -Tee-

Skip 4.x, and go directly to the FB5. From point of your app, FB4.x and FB5 are more than less the same, only minor ODS version change, form 13.0 to 13.1, so no new data types etc. If scared of new release, wait for couple of weeks/months to see is there something needed to fix (that you care about). If there is valid reason not to go to the FB5, I would for sure to skip FB3 at least, would jump directly to the FB 4.0.4.. Also I would try to avoid setting data type compatibility mode to some to the old version, I would just fix DB and code, should not take too long. Embedded needs exclusive access to the DB, so you need to close all connections to the DB, at the App and external Db tools etc. Not sure that is this the problem tough, because I saw no error message, and did not go through the german forum thoroughly. -Tee-

https://ib-aid.com/en/articles/detailed-new-features-of-firebird-5-part-1-improvements-in-optimizer My preliminary tests on our product(s) show that FB5 is clearly faster than FB4. Did not need to measure result, because you could see/feel it very easily. When you saw Vista Wheel with FB4, on top of FB5 you can't even see it, form just opens faster. For sure there will be some corner cases when some query, very carefully optimized for older version of FB will perform worse in FB5. At least always there had been some "regressions". But for every new Firebird release, there has been performance increase. FB5 is close to the release, so please evaluate is best as you can, and report any bugs or regressions ASAP, so they could be addressed before release. -Tee-

Not sure. maybe better to ask at Firebird mailing list. -Tee-

And Firebird 5.0 is out... https://firebirdsql.org/en/news/firebird-5-0-0-is-released/ Release notes: https://firebirdsql.org/file/documentation/release_notes/html/en/5_0/rlsnotes50.html Firebird 5.0 Language Reference: https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref50/firebird-50-language-reference.html Download: https://firebirdsql.org/en/firebird-5-0/ -Tee-

Hello, Was looking for what is out there and Interval tree etc has too much functionality than I need, but still might be way to go, not sure. I have ranges of integer, which do not overlap, and are inherently in right order while adding. In which I need to search if the given more than less random integer falls in any of those ranges, and retrive what type of the range is (Currently there is only two distinct types, and of course the state when integer value is not found in any of the ranges.) List would have 0-couple hundred of ranges at max, usually low numbers. That's why I was thinking that balancing of the tree structures while adding might be unwanted overhead. Was thinking using list that could use list, adn starts are in ascending order, and binary search, but was thinking how to binary search something that most likely is not in the list. Now that I write it out, have to just compare two items and/or is it first/last at the list, quite complex compare but nothing too bad, I think). For the list I was thinking that is there list implementation that can be marked as sorted without doing actual sort operation and would have binary search that could have custom compare that I could find the start of the range, maybe end of the range in the dictionary with start as a key. As you can see, I am not sure how this would be smart to implement.

I don't quite follow, could you elaborate a bit?

Most likely.

It sure would be handy and easy, with more than all features needed. I am afraid that it also would be too slow and too much resource overhead, There will be easily thousands of data structure populations and searches can raise millions even more. -Tee-

Very small ranges that would be simple lookup. I think I have to realistically be mentally prepared upper bounds of few hundreds of thousands, Maybe even millions. Most case it will be 100k or less.. But anyhow, interesting take on this. Thanks... -Tee-