Leaderboard

Hello all, Delphi supports 64-bit development since XE2. But somehow it is still not possible to list and import 64-bit type libraries ???? Kind regards, Arthur

Thank you; I'm reading this on a Linux box and thought I was missing something for a second. "Write programs to handle text streams, because that is a universal interface." - Peter H. Salus, "A Quarter-Century of Unix" Now, the question is how to handle this with Delphi... Delphi has never gained a simple solution for calling programs and getting the text results back, which is a weird and glaring omission in my mind. FreePascal has a handful of routines for doing so (some of which work across platforms), Qt has QProcess, etc. There's some information here on FreePascal's TProcess: https://wiki.freepascal.org/TProcess and there's a port of TProcess to Delphi (which I haven't tried): https://github.com/z505/TProcess-Delphi Otherwise, you're left with the somewhat complicated default Delphi way of doing this.... https://stackoverflow.com/questions/9119999/getting-output-from-a-shell-dos-app-into-a-delphi-app

Currently library supports formatting only for XML or XHTML. HTML formatter is expected in next version.

So? The IDE could spawn a 64 bit helper process to retrieve the info.

Hi all, I've added a small tool box to allow easy pattern matching in cases with many sub-cases. Have a look here: https://github.com/jkour/Motif Thanks

I strongly believe that it's something for everyone to consider. I'm 50-something in the MidWest and left my well paying job early this year for similar reasons. (I 'fired' my employer.) It's also related to a basic rule in life: Never work a job that you don't like. Think of the percentage of your life which is spent at/on work related activities, and if you aren't enjoying it and/or cannot stand the choices management is making and it's eating at your soul, then it makes no sense to stay there. Now, you certainly will always have minor annoyances, as no job is going to be perfect. And you may have to take a shit-job on occasion for special circumstances for a limited time, but it's a general rule that I've preached all my life (as my father before me.) If you are in a job that you don't like, declare it as a shit-job that's allowed to continue for a limited amount of time and find an alternative. I loved the vast majority of my previous job (and certainly disliked some parts) and I would have stayed, however the new private-equity installed board handcuffed me and my team where I simply couldn't do my job so I had to leave. I certainly have a distaste for private-equity types like the ones that have purchased Delphi and massively cut the R&D staff. They actually believe they can rely on cheap foreign developers for most of the work and the quality which is being produced today should provide ample proof that their plan is seriously flawed. But, they'll keep plugging away as the numbers likely look better with the much lower costs. And meanwhile we'll get repeated bad installs, required hotfixes after every single release (2 more today!), long-term infrastructure failures that should be a career embarrassment for everyone involved, platform support always putting out fires, and less and less core reliability. That's certainly not a successful long-term plan - so I assume their plan is to sell after showing large increases in bottom line due to all the cuts. But back to the job issue - I think it would be better to work for yourself. I'll never have another boss again. I ran my own side business for 7 years and sold it after the Great Recession was over so I could concentrate on my corporate job. Running your own business is not for everyone though as you have to be able to manage the risk.

Just an idea how you can quickly find out which of your units is broken: Units normally get initialized in the same sequence in which they are entered in the *.dpr file. So... my idea is to create a new empty "diagnostic" unit. Let it use only the "windows" unit and nothing else. For the rest, keep the interface section empty. In the implementation section of this unit, write an initialization that simply shows a "hello world" messagebox. This initialization will only execute if none of the units that initialized before it caused the program to terminate. So... Just start playing with the position of this unit in the USES clause of the DPR file. For starters, place it somewhere in the middle. Compile, and see if the messagebox appears. If yes, move the unit halfway further down in the USES clause. If not, move it halfway further up. See, we're doing a binary search here... Repeat this process until you have found the exact position where the messagebox no longer appears. It shouldn't take more than a dozen attempts. The offending unit will be the one right before the diagnostic unit. It's either that unit itself, or some unit which it depends on and which isn't in the uses clause.

The mORMot parser supports "extended JSON", as used with MongoDB: field names can be without quotes. It follows in fact the JavaScript object declaration syntax. Internally - between mORMot client and server - it will use it to slightly reduce size and enhance performance. For regular clients (e.g. JavaScript), it will server standard JSON with quoted field names. As @Lars Fosdal states, a rigid format seems better when exchanging data between heterogeneous ends.

Why inventing bicycles with triangular wheels when writing to STDOUT is a very simple method proven by decades? All *nix ecosystem is built on this mechanism. Executed app won't need anything more than WriteLn and executor app will have to intercept pipe handles.

I experienced a similar problem a while ago. From what I recall, it was a bad binary DFM which had to be isolated/corrected. For some reason, that experience came back to me after seeing your response. (Too many bad memories that have been suppressed!) I believe it turned out to be an ancient form (or two) that we hadn't changed in a very long time. Unfortunately I don't remember exactly how I found it among the many hundreds of forms in the project. I do remember searching for all binary DFMs and I believe I used the tool to auto-convert all the binary DFMs to text and it blew chunks on a bad DFM. It was either that or I manually opened all binary DFMs until I ran into a problem opening the form within the IDE. (It compiled fine and didn't cause errors in the app until some magic moment in time.) It was a few hours of head scratching for sure... Good luck!

Reading the stdout of the child process is a very easy way to do this.

The reason one pays for a subscription is for the product to be up to date. 64 bit support was hailed 7 years ago so I guess it's not unreasonable to expect it to work by now.