Leaderboard

The work on https://github.com/EtheaDev/SVGIconImageList continues, many issues have been solved. Now it's possible also to use native VirtualImageList (from 10.3 or 10.4) linked to a TSVGIconImageCollection! If you have an older Delphi version you can use TSVGIconsVirtualImageList. With the help of VincentParrent and pyscripter the components and the SVG library improve day by day ... Stay tuned!

Nonsense. Evaluation is always left to right. Period. No. That will suffer from boolean short circuit which is the whole point of this thread. Actually at this point it seems that the point of the thread has become for everyone to have a different opinion. I wonder why the simplest questions, with the simplest answer, always gets the most attention.

I can’t see past // must call all functions, defeat short circuit evaluation aVal := A(); bVal := B(); cVal := C(); Result := aVal or bVal or cVal; I don’t care for temporarily disabling short circuit evaluation. I’d rather have the predictability of one rule for expression evaluation. Mix and match adds an impedance to understanding for the reader.

ARPACK is recommended for extracting a small number of eigen vectors from a huge problem. LAPACK has effective methods for extracting all solutions using a direct method. Neither are easy to use from Delphi. I have done so but it isn't for the faint of heart. Especially ARPACK. The famous C++ Eigen library is very capable though and easy to use. I'd suggest you wrap that in a DLL. Start in Matlab to prove that it can do the calculation sufficiently quickly for a typical matrix that you will work with. Then write a C++ program in Eigen to solve the same problems. Does that work effectively? Then, and only then, try to wrap it up to be called from Delphi.

PyScripter, an Open Source, freely available Python IDE written in Delphi, has reached 1 million downloads from Sourceforge. This is in addition to many millions of downloads from its earlier home at the now defunct Google Code and an unknown number of downloads from other distribution channels. Historic note: The initial motivation was to build a good scripting solution for Delphi applications. About 20 years ago Microsoft was still promoting ActiveX scripting and Windows Script Engines (such as vbScript and jScript) as the way of building scripting solutions for Windows applications (one of many Microsoft technologies that was all but abandoned). At that time Python was relatively unknown, but it so happened that it was available as a Windows Script Engine and I looked into it. I loved the clean syntax, the expressiveness and conciseness of the language. Other things I liked were duck typing, batteries included, strong object orientation (everything is an object) etc.. The first iteration was an IDE (editor/debugger) for ActiveX Script Engines. But there were many bugs and limitations of Active Scripting both on the Microsoft/Windows side and the Python side. I then came across Python4Delphi which at the time was maintained by a Canadian developer Morgan Martinet. I started contributing to that project and later become its main maintainer, when Morgan's interested shifted to other things. I also developed a simple Python IDE which was named PyScripter and was originally distributed alongside Python4Delphi. There was very few Python IDEs available at the time and somehow the project became known in the Python community and instantly popular. For me, developing PyScripter was just a hobby, but I received a lot of encouragement and kept on improving it. I was also making some income from donations and Google AdSense. Both PyScripter and Python4Delphi were later moved to Google Code. Python popularity was steadily increasing and at the peak of PyScripter's popularity around 2010, there were hundreds of thousands of downloads the days following each new release. More recently as we all know Python became one of the most popular programming languages, but at the same time there was strong competition to PyScripter from freely available commercial grade IDE's such as Jetbrains PyCharm and Microsoft's Visual Studio and Visual Studio Code. PyScripter was almost abandoned when Google Code closed down due to my frustration, but after a couple of years of inactivity the project was moved to Github and development resumed. Downloads are available through Sourceforge, since 2016. Through the years PyScripter has kept a large and loyal group of followers. I get many comments along the lines "I have tried VSCode, I have tried PyCharm, but I keep going back to PyScripter". PyScripter is also quite widely used in many Universities for introducing Python to students. And almost 20 years after its first release, PyScripter is still going strong...

BRCC32? 🙂 Seriously, though. I have a batch script which crawls through a directory structure and creates a .RC file based on what it finds. As a final step it launches BRCC32 thisfile.rc and deletes the unnecessary .RC file. Works like a charm.

The welcome page always brought some issues, if you can, just disable it.

Since there were several questions that this sample doesn't work, I checked myself again. Indeed, it seems to be broken, out-of-the-box. I did the following to get it running: - re-create the project under Rx10.4 - add the Main unit to the project - check the Project/Forms tab, the main form should be auto-created - Removing all unnecessary permissions and entitlements, keeping just Camera permission - For some reason in uMain.pas, this line needed to be added. I have not cxhecked the orginal file again, but maybe there was some non-standard form creation. //21.08.20 added var CameraComponentForm : TCameraComponentForm; - For testing before, I moved the first creation, until the Camera shall be really started. This shouldn't be necessary, but I did that for testing to decouple the actions a little, und keep it in my final. That means you have to press START twice, 1. Get Resolutions, 2. Start camera procedure TCameraComponentForm.FormCreate(Sender: TObject); begin //21.08.20 PermissionsService.RequestPermissions([PermissionCamera], AccessCameraPermissionRequestResult, DisplayRationale); ... procedure TCameraComponentForm.btnStartCameraClick(Sender: TObject); begin //21.08.20 Try get resolutions here at first if cbResolutions.Items.Count = 0 then PermissionsService.RequestPermissions([PermissionCamera], AccessCameraPermissionRequestResult, DisplayRationale) else //only then start the camera with 2nd click PermissionsService.RequestPermissions([PermissionCamera], ActivateCameraPermissionRequestResult, DisplayRationale); end; Et voilâ, camera is working for me. I made some comments already, that I think the non-working samples and demos are a MAJOR SHOWSTOPPER, especially for new customers. If Embarcadero is making a trial, and CE version, they should better take most care that all samples will run out-of-the-box. If new customers trying new tools are a little bit like me, I will DROP the new tools immediately if I cannot get the basic demos and hello worlds running without major quirks. Thats my proof or quality for any software or tool. So its Embarcadero's marketing decision, not mine.

Exactly this is the way I would prefer like David says. If you change xVal to something meaningful, you will see why: Result := isDog or isCat or isHorse;

So...what was the problem then? How did you solve it in the end? I bet there is somebody out there still fighting with this issue.

One more, add const for argument aName.

Your helper is not going to work because what you want is a string helper (since the return value of GetAttribute is a string.

The helper is on the node. So you’d need to call vNode.ToInteger(‘Id’). I think you could do with a better name for the helper function.

How about something like this? uses System.SysUtils; function IsAnyTrue5: boolean; const Funcs: array[0..2] of TFunc<Boolean> = (A, B, C); var i: Integer; begin Result := False; for i := Low(Funcs) to High(Funcs) do Result := Funcs[i]() or Result; end;

If you use {$BOOLEVAL ON} and {$BOOLEVAL OFF} instead it will be a bit clearer what's going on. There's no point in passing Result along as a parameter. You're just doing an logical OR on the values in the list anyway. - and I do think you're being too clever. It's not a solution I would allow.

I decided to use Delphi's own TDBGrid for one of my projects; I personally don't like installing a full 3rd party suite for a single component if I can just fix the built-in up... Long story short, I did exactly what @Lars Fosdal advised - just added the very same Unicode character to the TField's displayname (I think that's the property...?). No complaints from users, they all like it. I don't use the standard grid, but as TDBGrid descends from it I suppose it's very, very, very limited too. The only reason I don't break out of my comfort zone and look for a cheap alternative is that I managed to fix most of the inconveniences already. If I'd go back in time I'd slap myself a couple of times not even to start with it. It was just waaaaay too much effort 😞 P.s.: my favorite "feature" is that the vertical progress bar had 3 positions: first record is active: topmost. Last record is active: downmost. Everything else inbetween - progress bar is at 50%. I seen no other component with this "design" yet.

Nothing, but in the past too many directives where bad for the health of Error/Code insight.. sure that's much improved now 🙂

@pyscripter Sometimes Im wondering what made Python so popular in the first place. Now I know, it was PyScripter IDE

function CompleteEval(const Values: array of Boolean): Boolean;

Your first two solutions are fine. Why try to be "clever"?

Guy is beating a dead horse with a stick. Another guy comes along "Hey, your horse is dead, you need a new one" "Nah... I am probably holding the stick wrong"

I see that from two sides. VCL-Side Is quite mature, bugfixes and new features OK, but who REALLY needs that ? No time pressure, low investment is maybe argueable. FMX-Side: Is under high pressure from more and more platforms (including Windows-10). Much more buggy than VCL, less mature, needs a lot of care in the future. Always time pressure, by Android/iOS time schedules, high investment is needed to cover all that. From the VCL-Side I feel quite relaxed, here and there a new language feature will do the job. Nothing is really missing here for my daily work. From the FMX-Side I can spot a massive under-investment. I regularily check the changes and additions to the feature API or mobile platforms. No or very little investment i to new API's and API changes there, only when its absolutely necessay. Why don't we have full API support for the platforms already, or at least 80% ? Why not simply put a task-force to translate all platforms API into Delphi, where mostly this would be routine work for mobile experts ? For example, why is not yet the cool AR/VR added, why did sensor-date had (maybe still have), why is camera still so slow, why not yet full Maps support, why not included full SSL-solution, ... ? Ok, there are solutions like TMSMaps, but why should I use them when Maps already were in the package. Thats what I always also have seen in VCL very sadly, why are many basic components so poorly and minimal designed, not meeting a minimum requirement in real world, just good for demo purposes. I want to use a Delphi FMX-Function, and want forget about the issues and problems behind. Embarcadero should flatten our way, and fix Location, Sensors, Permissions, etc. etc., so that the developers can use and rely on any function. Still there is too much special-knowledge needed, to get a many things running. I'm a lazy developer, want to use API's that do what they promise, don't need to know all details behind. The FMX-Side would be the right place to turn Embarcadero's future, if they could profile themself well as all platforms solution. In marketing yes they do already, but in realiity many of the promises were missing, and I can see not much work on this. A good indicator are also the demos and samples, which were revolutionary at those days, but getting lame and non-functional nowadays. Why is no ony improving, cleanup these features and add new demos permanently, because this is the main entrance for new customers too. I hope everybody understands, that when newbies checking an IDE where 50% of interesting demos don't work, they immediately take a step back and look elsewhere ( at least I do that with new technologies ). If everything works as expected, and without a lot of fumbling around, then the newbies will be catched more easy. These are only a few points where I would like to see a lot more investment. Still I hope for the time factor, so that it might get better in the near future, but for me an IDE which can support platforms out-of-the box should have a good weight in the market. For me mobile, cloud is clearly the future, combining with front- and backend desktop this is a killer feature. There are other nice boys in town, but they all have their pros- and cons as well, and IMHO RadStudio does not so bad in comparison. For the goal to achieve less "investment" gaps, I would like to see a much faster system of updates, patches and hotfixes, to keep us developers up running with high and accelerated pace against all other solutions.

We usually hold off moving to new major versions until Update 1 is out, but we do make the move. As far as I am aware, nobody on my team has ever had a problem with moving their IDEs to new hardware after XE4, and we use the regular named user licenses w/o any license server. Apart from the quality of the initial release, my biggest Idera/EMBT gripe at the moment is understanding why the f..k they keep spamming me with emails suggesting that I order 10.4 with a discount. Not only do I get these from EMBT, but also from the local reseller. I am on a subscription, FFS!

I see the change went through. All you need now is a friendly avatar 😉