Leaderboard

May be you can write the function in this way ? function cntCaseTbl(Z: Int64): Int64; begin if z >= 0 then Result := Trunc(Log10(z))+1; else Result := 0; //This should be, otherwise the result will be random value end;

Does not work for z = 0 though.

I have Tokyo Starter installed in a Win10 vm, along with a number of other Delphi versions. I fired up the vm, and ran Starter -- it worked no problem. I let Windows do some updates, then ran Starter again -- and again no problem. I don't know what to think. Is it possible there's some corruption in your Tokyo install? What makes you think Emba has withdrawn the Starter license?

I have tried all limit values 1, 10, 100, 1000, 10000, ....., 9, 99, 999, 9999, 99999, ...... And all the returned values are correct.

This is a code fragment that shows you how to convert python strings to Delphi strings with PyArg_ParseTuple function ShowMessage_Wrapper(pself, args: PPyObject): PPyObject; cdecl; var LMsg: PAnsiChar; begin with GetPythonEngine do begin if PyArg_ParseTuple(args, 's:ShowMessage', @LMsg) <> 0 then begin ShowMessage(Utf8ToString(LMsg)); Result := GetPythonEngine.ReturnNone; end else Result := nil; end; end; Also have a look at the PyArg_ParseTuple documentation. Using such methods is the low level approach to exposing Delphi code to python. Please have a look at WrapDelphi demos and tutorials for a high-level approach that that does not require you to use PyArg_ParseTuple or worry about reference counting and the like.

I guess I'd be a bit concerned about floating point use here when Log10 returns an exact integer

Hextor is a hexadecimal editor with a set of tools for binary data analysis and reverse engineering. Main features include structure analyzer, disassembler, regex-like search and many more. https://github.com/digitalw0lf/hextor I mostly write it as a tool for my main job tasks, but would be glad if it can be useful for community. Feedback and feature suggestions are welcome.

The only way is to get employed in Emba's compiler dev team, they have sources 🙂

Thanks for the feedback and sorry for opening the ticket as a "bug" instead of a "feature request"! Unfortunatly I don't have access to D2007 anymore. I only have an installation of 11 Alexandria available. I thought I considered all compatibility-problems and didn't use inline variables this time. 😉 The only scoped enum I used is "TMsgDlgType.mtWarning" right? Or did I miss another instance? I oversaw that and my version uses an action now as well. I would need two hints here: How should I open the file open dialog? There are only two overloads of ShowOpenDialog in GX_GenericUtils and both don't allow a directory as a parameter. Should I directly use a TOpenDialog dialog? Should I create an overload for ShowOpenDialog? How do I get the part of the path specific to the Delphi version? I couldn't find anything in the Embarcadero wiki to get the "19.0" for Delphi 10.2 or the "22.0" for 11.0. I was kinda confused at first when I wrote this import logic, because my settings were not saved. I imported the configuration file and the GUI displayed everything correctly but after a reload of Delphi all those settings were gone. That was the main reason I added the SaveEntries call at the end and the warning at the beginning. If I understand you correctly you would prefer if the import of the configuration file would not clear the root, but add a new subfolder called "wuppdi" (or similar)? As Daniel mentioned in the original wuppdi thread he does not plan to continue working on the wuppdi welcome page plugin, so I don't know if effort is necessary to sync the two files. The GExperts favourites have more options that the wuppdi wp as you can specify the "open mode" (IDE, custom, project, ...) and you can support an unlimited depth of subfolders which is both not supported by the wuppdi wp. It would be a hassle to sync the two files if one adds an entry from one of the two sides. I see this option more as a one-time conversion from wuppdi wp to GExperts favourites. This would surely be possible as an option, but won't work in all cases (especially in my case). I have Delphi 11 which is not supported by the wuppdi wp and so I don't have the configuration file in my BDS\11.0 folder. I would need to copy the old configuration file to the new directory to only use it with GExperts. So that doesn't seem viable to me. See my answers to 5 and 6. Attached is my current version of the patch with 1 and 2 addressed (hopefully). GX_FavFiles.pas.patch

Probably the documentation will help you: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Registering_Components

good to hear!

I started working with Delphi when it was first released in 1995. Prior to that I did embedded real-time work in C and was learning OOP with C++ when Delphi came out. For me, the 1990's were the most fun I've had in my entire career. I worked for a series of startups as their Chief Architect and Developer. They all died for various (non-technical) reasons, although one came very close to breaking out and becoming something significant. (Most of the people I worked with at Intel from 79 thru the mid-80's all went on to work with one or more startups and they all became multi-bazillionaires, a few even became billionaires.) By 2000 I was working entirely with Delphi. I really loved it. There was a lot of new work going on with it and it was a lot of fun. But by 2010, Delphi had been around for 15 years. Code had started to accumulate where the original dev teams had moved on ... to the point where there were well-paying contract gigs for people who had 5+ years of experience with Delphi, and I chased after them, but they got harder and harder to find. The next 10 years was a mix of contracts and regular jobs where the companies said they were looking for "experienced Delphi developers to lead projects". But they pretty much all turned into glorified maintenance roles. Over time, each new company / project got stricter and stricter in terms of what they would allow, and virtually none of it involved new product development. That was all being done in C#/.NET and the existing devs got to move to that stuff while contractors were hired to back-fill and keep the Delphi code running. It seems like the longer you work in a specific technology, the more expertise you're going to accumulate, and the more likely you are to be hired to maintain critical systems that use that technology. Companies like to invest in risk-reduction, so they seem to like hiring experts who are over-qualified for maintenance work. (Except recruiters from places like India who always say "I'm sorry Mr. David, but the client can't pay more than $21, maybe $22 per hour for someone with 10+ years of experience". They're trying to document that they cannot find Americans to hire in order to justify H1-B workers.) The Good News is that I just turned 65 and got on Social Security. I no longer have to deal with this crap just to survive, and I can start looking around for things that I *WANT* to do and I don't have to worry about the pay. I feel like I did when graduated from college! Except I'm now free of the "rat race" so I can really have some FUN with this technology. I've got some things I'm working on for myself, and was invited to be on the advisory board of a startup already. Things are really looking up.

I don't think it should be either or, why can't we have both? Instead if often seems that we have neither.

I am not confused. I am frustrated. I want both. Most of all, I want 64-bit debuggers that understand threads and make it easy and robust to focus debugging on specific threads, and that doesn't suddenly stop breaking on breakpoints or break on "invisible" breakpoints in Indy, or just purely stop responding completely. I'd love to be able to "disable" exception breaks for specific threads and only for those threads. I want the broken HighDPI properly and finally fixed. I want the code generation significantly improved for 64-bit. I want RTL, VCL and FireMonkey to be rock solid and efficient. But - also ... I want Generics constraints for enumerated types so that I can use enumerated type and set type operators. I want proper nullable type support, including the relevant operators. I want ARM support for Windows. I want ARM/Linux support for Raspberry PI. I want the static code analysis capabilities of FixInsight and similar, to be built into the DSP. I want a package manager that really works, unlike GetIt which is just a glorified downloader and installer. I want Swagger support for APIs.

Instead of hijacking this thread with yet another off-topic wall of text about why Embarcadero sucks and Delphi is doomed, maybe you could start your own thread? This was in reponse to the OP who posted a bunch of suggestions for delphi from a Developer's perspective. There have been tons of such posts here and elsewhere over the past decade, some quite eloquent and some more debatable. This discussion forum is dominated by DEVELOPERS, like you and I. We have our perspectives, we love Delphi and we all pretty much would LOVE to see it continue to grow and expand and get better. But after all of the proposals, submissions through official channels, and every conceivable attempt at begging, prodding, and encouraging Embt to do different things, it has become painfully obivous that ... they just are not interested. They don't "suck". They are operating in the best interests of their SHAREHOLDERS. We are DEVELOPERS -- NOT SHAREHOLDERS! SHAREHOLDERS want PROFITS while we DEVELOPERS want MORE FEATURES! Any overlap is mostly coincidence, driven primarily by Microsoft and Apple. Not us Developers. The CUSTOMERS paying the bills want LOW-RISK INVESTMENTS. Everywhere I've worked in the past 10+ years has had one thing in common: they only want me to touch code that HAS TO BE CHANGED. They don't want me to use NEW FEATURES. They don't want REFACTORING. They don't want the code "cleaned-up". A couple changed their policies that require every line that shows up as changed in the change logs must relate back to a specific trouble ticket. "Refactoring" for its own sake was not allowed. They DO want: simple, straightforward changes that use existing coding patterns and language features found in D7-era code (around when the apps were built) so it looks and behaves the same as all the rest of their code. The last place I worked, most of the core code they used in production had not been touched since 2007. I was told on my first day, "DO NOT TOUCH ANY OF THE CODE WITHOUT MY APPROVAL!" I found and documented several bugs, and was told point-blank, "you must be wrong, this code has not changed in over a decade; there are no bugs in it." Except it went from running in Win XP to Win 7 to Win 10, and now it does weird and unexpected stuff sometimes that I captured on camera. They didn't want to hear about it. I asked one Dept head (at a State Agency) why they don't rebuild their code in the latest version of Delphi using more contemporary stuff. His answer: Because their State's CTO basically said, "All new software development will be done in C#/.NET." Period. End of story. Seems their Legislature authorized a 10-year agreeement with Microsoft to provide them with everything they'd need, and that was that. I've heard similar things from multiple places I've worked, both public and private. This is NOT MY OPINION! I personally don't think Embt "sucks". I personally don't think Delphi is "doomed". I think Delphi's evolution is being dictated by two things: (1) SHAREHOLDERS who are only interested in profits; and (2) CUSTOMERS who are interested in REDUCING RISKS IN EXISTING PRODUCTION CODE. I love Delphi. I love the Developer community. And I don't see Embt's focus on Delphi changing any time soon to make it more aligned with that of Developers other than coincidentally. For example, I've seen dozens of proposals for language extensions, many of which would be useful to most Delphi Deverlopers on an almost daily basis. But the only two that were added to D11 ... I've never ever seen discussed. I was honestly totally surprized when inline 'var' declarations appeared in the language. That's a marginally useful feature to me, and not one I would have ever expected to see added. But its introduction broke a bunch of far more useful things in the IDE. They would have been better off not introducing it until everything in the IDE worked properly with it. D11 reportedly hasn't fixed anything that was in D10.4.2. The last place I worked, we were asked after D10.3 came out if there was anything added to the language that might justify the risk of upgrading everything. Inline vars were all there was, and the consensus was that they did not justify anything, especially because they broke a lot of stuff in the IDE. Unfortunately, the company went ahead and paid the maintenance fee anyway. Why? Because the cost of NOT paying was more risky and costly. Yet we're still waiting for MANY VERY USEFUL ADDITIONS to the language! This is how the game has been rigged: customers (companies) will continue to pay their maintenance fees whether they use what's been added or not. And SHAREHOLDERS LOVE THAT! Developers ... not so much.

This works for 10.3.x if you have some kind of PDF viewer installed on the device: uses Androidapi.JNI.GraphicsContentViewText, Androidapi.Helpers, Androidapi.JNI.Net; procedure OpenPDF(const AFileName: string); var LIntent: JIntent; LUri: Jnet_Uri; begin LUri := TAndroidHelper.JFileToJURI(TJFile.JavaClass.init(StringToJString(AFileName))); LIntent := TJIntent.JavaClass.init(TJIntent.JavaClass.ACTION_VIEW); LIntent.setDataAndType(LUri, StringToJString('application/pdf')); LIntent.setFlags(TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION); TAndroidHelper.Activity.startActivity(LIntent); end;

It seems, Emba has withdrawn all Starter Licences on all PCs without notice.

Since he already has a hex editor (looks like HxD in the screenshot), setting those bytes to zero would be easy. I don't really see the need for anything Delphi specific there at all

TL;DR Your discontent IMO has nothing to do with the topic and only sabotages the OPs attempt at a discussion.