Leaderboard

I think that original need to introducing [ref] was the need to force passing value parameters as references so they would match some cross platform API. I don't remember whether that was merely a difference between 32-bit and 64-bit Windows platforms, or there were other OS involved. I also don't remember whether C++ Builder support also had something to do with it. AFAIK, Allen Bauer explained this somewhere. I am not sure if this was only on his blog or it was also mentioned on old forums. New FreeAndNil implementation came years later and it merely used the feature that was introduced for other reasons.

If you have been updating the GExperts sources (or are following the activity on SourceForge) you might have noticed that there quite a few bugs have been fixed. That was not me alone (I am on vacation so I have some more time than usual) but also @Achim Kalwa (thanks Achim!). Many of these fixes were for the code formatter, but there are some more for glitches in the UI, in particular for scaling problems. read on in the blog post.

Try to add a class constructor and destructor to your custom control, like class constructor TMyTabControl.Create; begin TCustomStyleEngine.RegisterStyleHook(TMyTabControl, TTabControlStyleHook); end; class destructor TMyTabControl.Destroy; begin TCustomStyleEngine.UnRegisterStyleHook(TMyTabControl, TTabControlStyleHook); end; Of course you need to use your component class name instead of TMyTabControl.

Yes, no surprise - because const[ref] forces a reference type variable to be passed by reference - build version three of your routines that have their parameter as var, and you will see. Also, your reasoning about what you see is mistaken - if you retrieve the address of a parameter or variable that resides in a register, the compiler will reserve stack space for it to retrieve the address of it. In the case of passing a const string as first and only parameter that one will be passed in eax on 32bit windows, or rcx in 64bit windows - calling @ on that parameter cannot give an address if that parameter stays in the register, hence the compiler generates code to reserve stack space, and puts the value there and retrieves that address.

It will compile, but it won't behave as you are expecting. PROCESS_QUERY_LIMITED_INFORMATION is not a compiler conditional via a {$DEFINE} statement, "-D" compiler switch, or "Conditional Defines" list in the project options, thus: {$IFDEF PROCESS_QUERY_LIMITED_INFORMATION} // will always evaluate as false {$IFNDEF PROCESS_QUERY_LIMITED_INFORMATION} // will always evaluate as true Regardless of whether PROCESS_QUERY_LIMITED_INFORMATION has been declared as a constant in a unit that your code uses. That is where {$IF (NOT) DECLARED} comes into play, as it supports declarations of types, constants, variables, etc. Not to be confused with {$IF (NOT) DEFINED}, which is the {$IF} version of {$IF(N)DEF} and thus supports only compiler conditionals. const PROCESS_QUERY_LIMITED_INFORMATION = $1000; {$IF DECLARED(PROCESS_QUERY_LIMITED_INFORMATION)} // will evaluate as true {$IF NOT DECLARED(PROCESS_QUERY_LIMITED_INFORMATION)} // will evaluate as false {$IF DECLARED(PROCESS_QUERY_DOESNT_EXIST)} // will evaluate as false {$IF NOT DECLARED(PROCESS_QUERY_DOESNT_EXIST)} // will evaluate as true That is a compiler/IDE bug that would need to be reported, with example to reproduce it. I don't get that error in my tests. Sure, though you would be using your own constant declared in your own unit, and not using a constant declared in the Winapi.Windows unit if Embarcadero ever decides to add it in at a later time.

You probably copy/pasted the code from here and therefore got the looks-like-space-but-isn't Unicode characters the forum pretty-printer sometimes uses. Type it by hand and it will most likely work. Apart from that, why are you even bothering with {$if declared} at all? Just declare the constant unconditionally, FSS. It's not like you will break anything if it's already declared.

Maybe if you want to use ASM to access the parameter?

You can also use remote lab: https://developer.samsung.com/remote-test-lab

It also depends on your need to access the hardware on the computer. If you need to access microphone, camera, harddrive, audio, USB devices, etc. you have much better control with an installed app. It is the case with both desktop and mobile devices. That's the reason we release our app on Windows, MacOS, Android and iOS.

Considering every major ERP vendor is moving to cloud, I would say that the trend is "no". However, these are typically enterprise sized ERP systems. There may be a niche for small shop owner ERPs - but there are already tons of these out there, and even some of those are cloud based. As soon as you exceed a single user, you are in database territory, and when you talk mobile apps, you definitively are in web service country. I would suggest that you really research your intended target audience to see if there is a gap where a desktop app could fill a need. I would also suggest that you narrow down and "modularize" your functionality, because the concepts of ERP systems and their near relatives are REALLY far reaching. You may suddenly find yourself in Tax, CRM, HR & Salary, document management, EDI and WMS territory.

I believe many people prefer native desktop applications to the typical bloat of a web application. There are some exceptions, and I am an older guy with heavy bias, but I would pay double for a native desktop application over a browser based application for just about anything. If I wanted to use it on my phone, I'd take a scaled down version, targeted with features needed to be available on-the-go.

If you start by 0, I would also say no, this should not be underestimated, If your question goes in the direction of an existing ERP bringing to web technology, I would say yes. Otherwise C#, PHP/Laravel or even Python will close that gap nowadays. Even large ERP systems were developed with web-technologies much faster and much more capable than desktop, before we even can start an *.EXE file This is just my opinion, perhaps there were different opinions or experiences too.

For me, the generic answer would be "no", but you have to look at the use, the need and adapt. A lot of software goes online for reasons of maintenance and “simplified” access everywhere. If your software needs to be used from smartphones and desktops, the simplest solution will always be the website (even if it's sometimes complicated to do, even with tools available for Delphi developers).