corneliusdavid

First of all, you need to more narrowly define "freelancers". Are these developers? Or marketers? Or AI consultants? Are they people you'd find on Fiverr or Guru.com or some other such site? Are they young or old? If you want to hit all these markets, definitely making it cross-platform (Mac and PC) is a plus as there are many more people using Macs these days. However, the younger generation tend to live on their phones and do everything online so having a mobile option would be key to tap into their preferences. Us old codgers like to manage our own stuff on our own machines, so an offline invoicing program that doesn't require an expensive annual payroll module to be updated is a great sell. (Of course, these are over-generalizations.) In my opinion, when purchasing a program in this category that promises to solve several needs, it should definitely be feature-complete for the features you want to promote. Release updates to fix bugs as frequently as necessary without annoying the customer (couple times a month at the most) and then major updates to add features but putting something out that has known bugs or pretty big missing parts will kill your reputation unless you're giving away free beta versions to get people hooked and then a steep discount when version 1.0 is released. Also, releasing something with spots for features that are "coming soon" will worry potential customers about how realistic and timely those can be expected, especially for a new player in the market. This is made worse if there are other programs that already have these features--hard to convince someone to move to a new software that can't do as much as what they're currently using; you don't want to advertise your product as a competitor if it doesn't really compete yet. On the other hand, you don't want to take months or years developing a product only to see the market shift and find your product irrelevant (this happened to me); of course, invoicing for freelancers isn't a market that is likely to go away any time soon. For mobile devices, using the device's store app is essential, not so much on desktops. I never go looking in the Microsoft Store for apps, I search the internet first and if it happens to point me to the MS Store, then I go there to get it. You'll definitely need a code-signing key to help people trust your software; and you might need to get the more expensive "EV" version to increase trust. But otherwise, sending out a Setup.exe is something I still expect. Others may point out shifts in the industry but they're moving slowly. Take all I say with a grain of salt; I have done very little commercial product development and marketing. Mostly what I have written here is my own opinion as a consumer (and former short-lived freelancer). There may be many other people with better and more relevant experience than I.

Thank you very much--lots of good information. I just checked and my (very old) Yubikey is Firmware 4.3.7. I don't know a lot about Yubikeys and I don't have a great need for a signing code anymore but this sounds like the cheapest way to go, even if it is a little cumbersome. I had also looked at gogetssl.com from one of your other posts on this subject, but 3x the price.

I stand corrected.

Is Atozed still alive? Is there still progress being made on Intraweb? I had looked into that years ago and they were stuck on a major upgrade for a very long time (years) with no news. It seemed like an easy-to-use platform but I would seriously question their long-term viability. If you've had recent contact with them, perhaps I have outdated opinions. UniGUI is pretty neat, but a completely different way of doing web development. If you're using WebBroker and need session management, that capability was added in Delphi 13.

I got the same email this morning. I've been looking around for a cheaper alternative and found SSL.com. It looks like they support Yubikeys; I have an old one but can't find information about how to use it with their signing process--perhaps it's part of the request?

No, but I've gone the other way: took parts of a Windows service app and made a WebBroker server. I did that several years ago as a demo in a book I wrote. You can download the code for those projects from Github; chapter 12 talks about Windows services. An ISAPI DLL is still the way to go for writing Windows web server apps with Delphi under IIS. What are you trying to accomplish by converting it to a Windows service?

When you buy a new license, you can request then download previous versions. Yeah, still expensive but that's how it's possible to get a previous version if you really need it.

Interesting. I've been playing around with a test project and it appears that when you apply LiveBindings to the grid, it hijacks the properties--and hides some of them. Your example is not using LiveBindings, mine was. As soon as I removed the table and LiveBindings components, then I could edit the column header TextSettings at design-time as you showed. I so seldom use StringGrid and then almost always use LiveBindings to hook up data sets, I had never encountered this before. Thanks for your screenshot.

Yes, but the Header is only a simple string, it does not have a TextSetting sub-property. And the TextSettings property for the column in the object inspector only affects the data, not the header:

There is no HeaderSettings directly off the StringGrid itself. However, it got me thinking... This line of code works: StringGrid1.Columns[1].HeaderSettings.TextSettings.HorzAlign := TTextAlign.Trailing; But, frustratingly, you cannot access the HeaderSettings of a Column at design-time.

Firemonkey doesn't have data-aware controls like the VCL does. Instead, you use LiveBindings which is more flexible and powerful but has a learning curve. I would suggest activating the LiveBindings Wizard to make hooking it up simpler: in Tools > Options > IDE > LiveBindings, check the box for "Display LiveBindings Wizard in context menu". Then in your form, you can right+click on control (such as the grid) and select "LiveBindings Wizard" which will walk you through hooking it up.

Did you want screenshots of the configuration? I can generate them for you.

I have looked for a way to adjust the caption titles as well and there doesn't seem to be a simple property like you'd expect. I suppose you could implement a custom draw event but I haven't needed to because I use Woll2Woll's FirePower grid for FMX and it does allow custom title alignments with a simple property.

Yes, I agree with this when you've done all you can reasonably do to catch/handle/prevent problems and there's a top-level exception-catcher to report/log bugs. But to not use any try/except strikes me as a very bad rule.

I do. But each to their own style. To me, the extra verbosity makes it more cluttered. I much prefer the curly braces of C-like languages because the words "begin" and "end" just get muddied in with all the identifiers and "real" code. But I'm stuck in Pascal and so use "hanging ends" on if statements and so forth to save an extra line. I try to use as little vertical space as possible. And blank lines after begin and before end, etc.? I personally feel that's wasteful because to me, the indentation is enough to identify a block of code; I reserve blank lines for separating groups of contextually related code. Like I say though, each to their own.

I find this to be a surprising and very strange statement. As programmers trying to provide a nice, smooth experience for end users, our job is to handle a wide variety of situations that we may or may not foresee. When writing to a file, for example, you should check to see if it exists and if not, create it, then start writing. But what if it's locked or read-only, or has a permission error, or has some other corruption, or a network error? Are you supposed to check for every possible problem proactively so that you don't have to use a try/except as a general catch-all? It's far better to write an exception handler that gracefully logs the error and puts up a message to the user rather than letting the system generate an ugly default error message. If you detect an exception is getting generated often, figure out how to prevent it so it's not raised; but the idea to just let it go because you don't know what to do baffles me. Many times, library calls or third-party components will raise exceptions for unknown or unhandled issues; if we don't handle them, it's just unprofessional. Another example: We have a parsing function in our library that expects strings to be in a certain format--and 99% of the time they are. To save programming time, we assume it is in the right format and just parse it. But that routine is in a try/except and if for some rare reason the string is not able to be parsed, the except clause displays the invalid string. Then we can correct the source of the problem rather than have 40 different if/else clauses or a complex regular expression to catch every possible nuance. Using try/except in this case saves a lot of programmer time. One more thing: Exceptions are NOT always errors. But--you should know this! Am I missing something in your statement?

Personal opinion: I think @pyscripter's suggestion is far clearer than try try except end finally end When filled with code and logic branches, etc. this multi-level indentation gets messy, plus two extra lines for the extra try/end in the middle.

I've had no problems with LSP in D13. After seeing your post, I tried both LSP and classic in both 32-bit and 64-bit. CodeInsight works fine in design-mode for the small test project I looked at. In debug mode, hovering your mouse over identifiers will (try to) show the value of them, not the definition. Perhaps you're confusing the context.

No, you do NOT need .NET to access REST APIs. Nope.

Ah--missed that! Well, Delphi still uses MSBuild (MSBuild tasks are .NET assemblies) so that might be what is being initialized. I guess there's still some .NET dependency.

OK, I admit I've never had an application form open at the same time I'm recompiling a component package (or it's been so long, I forgot), so would never have seen something like that. As far as I knew, it was a disconnected relationship between the libraries and wouldn't visibly affect anything until you refreshed or activated the form again somehow (or, in my case, opened the application with a form containing those components).

No, it just recompiles the DCUs/DCPs/BPLs; doesn't touch the design-time parts. Yes, I believe so. If you add a component to the package and then recompile it, it'll tell you about the new component that has been registered. So is it any and all packages or just all that you've tried or just one of them? The error shown indicates it might be DCPCrypt? I worked with a package recently that was upgraded from a messy Delphi 5 library and when I added one of the units that had been recently upgraded, it caused an access violation every time I closed Delphi. I didn't realize it at first and it took me awhile, restarting Delphi, recompiling the packages, installing, uninstalling, until I finally figured out where the problem was and fixed it.

The 64-bit IDE is still quite new. Do you have the same problem with the 32-bit IDE? You might file a bug with Embarcadero. If it is a third-party package, it might be tedious restarting the IDE multiple times, but it might be what it takes (I know, I've had to do this on occasion to troubleshoot my own packages!).

I believe all the last bits of .NET have been removed from Delphi 13 so if you ever upgrade, you'll no longer be afflicted in this way.

This is a very strange statement. Delphi isn't "positioned" to read old ugly code, it's purpose is to read and compile Pascal code. Pascal, in its definition, does not require any style of indentation; in fact, the code here can be compiled. "Readableness" is in the eye of the beholder; what looks good to one programmer may look horrible to another. I've inherited code where all the begin's and end's were indented to the same level as the code body and it was difficult for me to "see" logic blocks because I'm so used to looking for "standard" indentation styles. After applying my formatting rules, I was able to scan code much more quickly. You make a lot of statements that you assume applies to everyone. Like @dummzeuch said, "some people think different." I have found the extract method to be one of the most useful refactoring tools. For example, as I'm writing a procedure, I think it will be relatively short, so I put everything I need right there; then as I add more, I realize it should've been broken up into parts. That's where the extract refactor is quite handy as it moves associated variables, declares the new method, and adds the call in the original code. That saves a lot more time than renaming a variable name (ever heard of search-and-replace?) or declaring a variable (create a quick bookmark, jump to a declaration area, create the variable, then jump back to the bookmark). Everyone works a little differently and has different experiences.