Leaderboard

After a very, very long beta phase I finally released MMX Code Explorer V15. Thanks to all beta testers for their help and patience. A really big thank you goes to all who donated for the new MMX icons.

I don't care about nullables so much as a more efficient way of writing code that tests for a NIL value and stops rather than raising an exception, so you don't need to have if Assigned( xyx ) then all over the place to prevent exceptions. Nullables seem like a back-door way to get support for something that would save quite a bit of time and coding that isn't going to be added to the language just because it's really useful. There are so many idiomatic phrases we use habitually simply because the language never supported ways to avoid them originally; other languages are finally being enhanced to address things like this, but Delphi remains stuck in the Dark Ages when it comes to useful language enhancements. Like the use of strings on case statements that practically every language in use today supports, just not Delphi. Compilers are supposed to make the work of programmers EASIER. I don't subscribe to notions that "we don't do that because it's not in the 'spirit' of Pascal" or whatever. That's just BS. It's like saying you'll never put an electric starter on your cars because it's just not historically accurate with original car designs. So you have to get out and crank a lever in the front of the car to get the engine started. I don't know about anybody else, but I'm sick and tired of hearing off-the-cuff comments from managers and VPs who make technology usage decisions saying that Delphi old and stale so they can't wait to replace their code with "a more modern language". At the place I started working at in mid-January, the CTO cornered me one day after I'd been here about 3 weeks and said, "So how much work do you think it would take to replace all of the Delphi and MySQL with C# and SQL Server?" Why is this such a pervasive and recurring question everywhere I've worked for a decade? There may be something heart-warming about the fact that Delphi can compile code written in 1995, but it's keeping management teams at corporations of all sizes from embracing Delphi because there are plenty of language enhancements in C, C++, C#, Python, Ruby ... you name it, that are not in Delphi, and from all indications will never be. That gives the clear impression that Delphi is old, stale, stodgy, and is something nobody wants to use because it has no support fo the latest language features that other languages have. For 12 years now, I've worked at one place after another where my job was to keep a bunch of legacy Delphi code alive until they can replace it with "something more modern". That's THEIR words, not mine! And I have absolutely no defense for it. They use the Pro version of Delphi, not Ent or Arch, because they don't use any of the other stuff bundled with the bigger packages. Just the language and a few 3rd-party component libs (mostly free stuff). There are other tools that implement Pascal variants that are almost totally compatible with Delphi, and add plenty of new language features that are on-par with contemporary languages. These prove it can be done elegantly and cleanly. But the compiler builders need the motivation to do it. If the folks who own Delphi ever hope to get it mainstream again, they need to bring the language into the 21st century and add features that most other contemporary languages have had for a while now. But when the topic comes up, all we ever hear is crickets. "Oh, but look at all the work we've done with our latest Interbase enhancements!" There's lots and lots of work being done enhancing stuff that hardly anybody uses. But enhancements to the core product are nowhere to be found.

Well, I am sure you will understand that it's not really nice to advertise another product in a thread specifically presenting HxD. I have invested many years into it (since 2002), and it has been Freeware all the time. A little respect for that effort would be appreciated.

I try to separate all code into platform separated untits meanwhile, even if this can get more work. But the IFDEFs tend to get messy very soon, even in small units. Even if the units are getting very small and simple, I found for myself that its very worth it to get a clean structure. unit MyUnit type TMyBaseOrAbstractClass = class or better an interface end; uses {$IF DEFINED( ANDROID )} MyUnit.Impl.Android, {$ELSEIF DEFINED( IOS )} MyUnit.Impl.iOS, {$ELSEIF DEFINED( Macos )} MyUnit.Impl.Macos, {$ELSEIF DEFINED( MSWINDOWS )} MyUnit.Impl.Win, {$ELSEIF DEFINED( Linux )} MyUnit.Impl.Linux, {$ELSE} {$MESSAGE ERROR 'MyUnit: unkown platform' } {$ENDIF} FMX.DialogService; ... unit MyUnit.Android uses MyUnit; type TMyBaseOrAbstractClass_Impl = class( TMyBaseOrAbstractClass ) end;

Samples are frequently just showing some features. They don't have to be examples of perfect design. +1 but I'd add "if possible". Surely one should estimate complexity of common interfaces and IFDEFed fragments. F.ex., IFDEFs in uses clause are hardly avoidable. But minimizing platform-specific IFDEFs (and other IFDEFS as well) should be the priority. Luckily with inlining wrapping platform-specific code into a common routine even won't cause a performance hit. Anyway separating platform-dependent and platform-independent code is nice and useful exercise. F.ex., one could discover that full file paths may contain no drive letters, or libs may have extensions other than "DLL", or that handy PostThreadMessage function is missing xD

Spend some time looking at the development process and quality over in C# and .net land, and then see if you honestly can regard Emba's process and quality even remotely in the same ball park.

HxD is a Freeware hex, disk and memory editor, that is fast and can handle files of arbitrary size (up to 8 EiB). Some of the feature highlights are: Disk editor (automatically unmounts drives as necessary when saving changes) Memory editor (full support for 64 and 32-bit) Data folding, for easier overview and hiding inaccessible regions Data inspector Converts current data into many types, for editing and viewing Open source plugin-framework to extend with new, custom type converters Search and replace with support for various data types Importing and exporting of Intel Hex, Motorola S-Records Exporting to Pascal, C, Java, C#, VB.NET, PureBasic, but also HTML, RTF, and TeX Checksum and hash generation and validation File compare Tools to split, join and shredder files Currently, available in version 2.4 and 17 languages: HxD download. P.S.: If you like it, please star the code on GitHub or give it a (good 😉) rating on download sites.

@Fr0sT.Brutal Yes, did that before. Tends to get very ugly and messy with ios and Android soon. Thats why I changed my method.

As a file viewer (not editor) for very large files and with UTF8 support there is nothing to beat V from fileviewer.com. I ignore all the file-manager stuff and use it, daily, as a file viewer.

I'd start with all platforms in a single unit but split it as you do if it grows larger

Thanks for your Tips @vfbb and @Rollo62. After i have recreated project file now it works.

@timfrost You can workaround that by renaming the registry key HKEY_CURRENT_USER\Software\Raabe Software\MMX\14.0 to something like 14.0_hide. After installing V15 you can rename it back. You may have to adjust your V15 settings manually then. I will try to setup a similar scenario to track down that problem.

Ugh, the code you write shouldn't need those ifdefs. That the entire point of you using the libraries provided by others, like Emba. They present a common interface to you. That's the entire point of cross platform coding.

Did you "upgrade" your old project from 32 to 64-Bit ? As the platform 64 was added, the automatic conversion of the IDE might fail. As vfbb proposes, check the libraries. Maybe even better, try to completely create a new project file, as 10.3.3 might put all necessary files into it.

Compile with Android 64 with AAB Bundles enabled and selected the Application Store configuration. But before it, check the Libraries (jar files) of the Android 64 bits, some jar file may be missing. Note: when you compile the AAB, to make the Android 32 and Android 64 packages, the delphi will only consider the jar files from Android64 libraries... I had the same problem, because my Android 32 had the google vision jars but after made the AAP Bundles, in the Android 32 bits the jar files weren’t there.

Seems the CS logging switch was a coincidence. I finally found the actual bug.

Actually I don't need new broken stuff at all - regardless of existing bugs being fixed or not.

YES, exactly that! However many Delphi developers have a troubled past where often "new" things turned out to be broken, caused problems or were simply not thought through entirely and just slapped onto existing things like duck tape. Like using attributes like [ref] in addition to the existing keyword const just because of the fear to introduce new keywords or introducing inline variables (that had many bugs) without the entire tooling understanding them and stopping to work. So many people are in the mindset of "don't touch it so you can't break it" and "fix the existing bugs before adding new broken stuff"

I try to ensure that all my text files have a BOM and are encoded as UTF-8.

The main change about the language would be the full ARC removal. The memory model is really part of the language, to my understanding. It is just as vital as to operate with "class" itself. Pure unfair FUD trolling remark: managed records are available in FPC trunk since a few months, and I guess EMB doesn't like to be behind an Open Source compiler. 😉 We implemented Nullable types using variants, and integrated support in our ORM. It has the advantage on working since Delphi 6, with low overhead, and good integration with the pascal language. See http://blog.synopse.info/post/2015/09/25/ORM-TNullable*-fields-for-NULL-storage - back from 2015!

No feature freeze until Delphi Antarctica

I'm looking forward to a ton of bug fixes and performance improvements, for the IDE, the compiler(s) and the resulting executables. Considering the code name "Denali" is based on a mountain in Alaska a feature freeze could sound likely, but I doubt it. When Delphi Anchorage is finally released it will have some cool new features along with the obligatory cool new bugs... *Sigh*

I was having the same issue. It started shortly after adding the ToDo list to the dock panel. To fix: Make a backup copy of the dst file. Edit the dst file and location the DockSite0 section. Find the entry for TabDockClients and remove any clients that you may have added recently. I believe the default value for that entry is, "RefactoringForm,PatchForm,FindReferencsForm" As soon as I removed "Todo List" the exception stopped appearing.

https://en.wikipedia.org/wiki/Hyperbole

The eternal optimist