corneliusdavid

It's just my read on it based on what I've seen.

2 minutes ago, Anders Melander said:

they want you to buy the product

because they can make more money selling deployment licenses.

I guess time will tell.

4 minutes ago, Anders Melander said:

Actually, IMO it is more likely that RAD Server will be discontinued before DataSnap is.

I highly doubt that. There have been a lot of updates to RAD server recently. Also on https://blogs.embarcadero.com/, there has not been one single article about DataSnap since 2020 while there have been 15 on RAD Server in that same time-frame.

DMVCFramework is a good way to build a REST server; it's open-source, well supported, and well documented but has a steep learning curve for newbies. RAD Server also allows you to build a REST Server but requires the purchase Delphi (or RAD Studio) Enterprise or higher, so it's not cheap if you don't already own that edition of Delphi.

But neither of those solutions are explicitly "database in the cloud" products. They can be written to access databases and provide remote data but you can also host a database in the cloud and access it remotely from a standard Delphi app using database components. There are many reasons why building a REST server is a much better way to go but just thought I'd mention the option as I have done both.

1 hour ago, dummzeuch said:

On the first page of the wizard, there is a button for doing that,

It's the "Options" button and takes you to another page that is usually skipped; on that page, you can set the destination for both RAD Studio and the Catalog Repository folder, and also determine whether it's installed for "all users" (the default) or just the current user and whether or not to add a shortcut on the desktop.

2 minutes ago, Unktneemo said:

Also, i have another instance running on other locations around the state, with RemoteApp. And they are working fine. Same windows, same software.

It began to fail recently. That is the strange thing.

Oh, some instances work fine? Then perhaps the users getting the error are accessing the one part of the program that doesn't work well with RemoteApp. It'd be interesting to know what the difference is between the ones that work and the ones that don't.

One thing I remember from testing is that the software seemed to work fine while the user was in the main program; messages popped up, multiple windows, database access, fine (with permissions set properly).  But the software was split into about four applications and when they needed to launch an ancillary program, there were problems getting to it. RemoteApp likes to be in control of the programs that are launched and, IIRC, this was the biggest hurdle we faced.

7 minutes ago, Unktneemo said:

hey say that there is no problem with the software.

Yep, the software I was testing was very mature software, having run for hundreds of clients around the US for many years. And, like you noticed, some parts work fine, other parts raise errors. There may be simple software fixes to get around those--really depends on the program and what it needs to do.

I support some programs that are accessed via RDP and when I was first researching remotely running apps, I tried RemoteApp briefly but had a similar problem. While I don't recall what the exact cause of it was in that instance, it has to do with the application assuming resources are accessible in the same manner as they are when run from a standard Windows desktop--which RDP provides. It may have been something simple like checking for the screen size or something. In any case, we had to modify the program and even then only run it via RDP. I'm sure it would work through RemoteApp if it was a fairly simple program but when the Delphi code calls Windows API functions that are either not supported or return unexpected values and they aren't handled properly, weird things can happen.

Sorry I don't have a better answer but yeah, you'll need to talk to the programmers.

6 hours ago, Uwe Raabe said:

No need to check for existence as the internally called _UStrDelete already handles that case pretty well.

Ah Yes! I love it!

2 minutes ago, Lars Fosdal said:

I replaced shortest with most readable years ago

I agree it's not near as readable. But it was sure fun to see if I could do it!

Excellent! Glad that helped. I just found a similar property in a DevEx grid control a few weeks ago with a similar need/solution.

So here are three ideas that might help:

1. Customize the Color property of each tab (RzTabSheet) at design time (which doesn't affect the sheet's background color, just the tab color).
2. Hook into the OnChange event of the RzPageControl and set the RzTabSheet's color for the selected tab.
3. On the RzPageControl, uncheck the seFont option of the StyleElements property. I think this ignores the color that the Wedgewood Light theme would set and uses the Windows standard font color (clWindowText for this element).

Using the third option, here's what my test looks like:

If by "shortest" you're trying to keep it to one line, this will work (you have to use the Math and StrUtils units):

Result := IfThen(Pos('<', MyStr) > 0, Trim(LeftStr(MyStr, Pos('<', MyStr) - 1)), MyStr);

I'd say it's the color choices the RzPageControl chooses to use for it's background--partially because it uses a dark one for the tabs, so to make the selected one stand out, it uses a light background, which for Wedgewood, is too close to the font color.

Here's a form using the Wedgewood theme with both the Standard PageControl (on the left) and the RzPageControl (on the right):

The Sterling theme looks a little better as far as the contrast for the selected page but the whole form looks washed out (IMHO):

The Aqua Light Slight seems to work well for light-colored themes:

Just try several different themes until the control gives the right balance of colors in your application.

This doesn't directly answer your question but I did some comparison of the IOUtils paths on various platforms and learned a lot while writing this small open-source app: https://github.com/corneliusdavid/AppPaths. Maybe it will reveal some access limitations on iOS.

Which of their products? From their website:

• StyleControls: XE2+
• ImageKit: XE3+
• SmartEffects: D5+
• BusinessSkinForm: D5+

So if you're only needing the last two, then Yes!

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Connect_to_Microsoft_SQL_Server_(FireDAC)

8 hours ago, MJBComp said:

Can you explain why when i open the Delphi Template Manager and try and delete the "if" template it won't actually remove.  It will show as deleted. But if i close the Template Manager, close and re open Delphi the "if" template is back.

Probably because the default "if" template is under C:\Program Files (x86)\... which is read-only. I'm guessing Delphi removes it from it's run-time list while it is open but re-populates the list from the files when it starts back up--and since the file itself was not deleted, re-reads it.

If you really, REALLY want that "if" template to go away, close Delphi, manually delete C:\Program Files (x86)\Embarcadero\Studio\21.0\ObjRepos\en\Code_Templates\Delphi\if.xml, then re-start Delphi.

1 hour ago, MJBComp said:

Its the "if" Delphi template causing it.  But when i delete that template the behavior still remains.  If i close Delphi and restart the template is restored back.

 

If i try and modify the "if" template and try and save it i get this error:

"Unable to create backup folder 'c:\program files(x86}\embarcadero\21.0\ObjRepos\EN\code_templates\Delphi\_history\'

Yes, this is the Live Templates feature of Delphi (one of my favorite productivity features, actually). A default set of templates gets installed in C:\Program Files (x86)\Embarcadero\Studio\21.0\ObjRepos\en\Code_Templates\Delphi as you discovered but remember that anything under C:\Program Files (x86) is read-only by default, so renaming or changing a Live Template from Delphi might not affect the actual file--or, as you encountered, you'd get the "Unable to create backup folder" error as Delphi tries to create a backup of the template before saving the new changes (which it will also fail to do unless you're running Delphi as Administrator).

In addition to the default templates mentioned above, any new ones you create are stored in C:\Users\<your username>\Documents\Embarcadero\Studio\code_templates\Delphi. Since your user folder IS writable, you can rename/modify/delete the templates there all you want.

You can turn off the auto-completion of the templates (which forces you to hit Ctrl+J to activate one) by going into Tools > Options > User Interface > Editor > Language, switching to the "Code Insight" tab, and unchecking "Auto complete" under "Code template completion".

OK, one more interesting thing (I keep thinking of different ways to test this...): I was running D11 DPI-aware on my High-DPI monitor and it worked fine. When I right+clicked on the data module's editor tab and selected "New Edit Window" to open the data module in a separate (non-docked) window, then moved that window to a regular-DPI monitor, that's when I started having the same problems you described: moving components then saving, moved them back. If I re-docked the floating editor window back in Delphi, the problem stopped; if I moved the entire Delphi IDE to a regular-DPI monitor, the problem also stopped.

I just encountered something somewhat related that may give a clue--and definitely ties in with DPI. In attempting to replicate your problem of non-visual components being repositioned, I opened up a data module in Delphi 11 and tried moving the components around and saving to see what would happen. Just now, I opened that data module up in Delphi 10.4 (after saving it in D11) and saw the components had been spaced out and the data module "form" itself was twice the size. I also noticed that D11 had added the PixelsPerInch property to the data module (which Delphi 10.4 had to strip out upon opening it).

The DPI-unaware version of Delphi 11 does not affect the placement or sizing of the data module or its components at all, nor does it add the PixlsPerInch property.

3 hours ago, Damon said:

Here's another issue that seems to be only high dpi occuring.

Wow, that's really weird.  I've been using Delphi 11, DPI-Aware for a few months now and have several data modules and forms with non-visual controls and they have never been repositioned.

Do you have any IDE Experts installed?  Is this VCL or Firemonkey? 

LOL! We're all there at one point or another.

Well, they could've limited it to edit only the currently selected theme. That might have been a little less confusing but it would be tedious if you wanted to configure several different themes at once--you'd have edit options for one theme, save, go switch your theme, then go back into the options and configure the next theme. What the "Edit Layout" does is simply take you to the Welcome Page section of the Tools > Options page where you can set a custom background for each theme all before leaving the Options. (And you can get there, of course, without even clicking the "Edit Layout" link from the Welcome Page.) Thinking about it from that perspective makes sense (to me).

To find the original background images, you can click Load... on one of the themes where you haven't yet changed the background theme, then look at the File Name box; the filename of the currently selected background is shown there. On my system, that folder is C:\ProgramData\Embarcadero\BDS\22.0\Background images.

To reiterate what Uwe is saying, let's take an example. I have my theme set to Dark. I go into Options and set a custom background for the Light theme, save twice, and I'm back to the Welcome screen where my dark theme's background is unchanged. But when I switch to the Light theme, there's my new background.

You're saying this does not work for you?

If you have the separate date parts already, I would definitely agree that EncodeDate is better. But if you're parsing a string, hoping it's in a date format, using TryStrToDate can avoid the exception, like @Remy Lebeaumentioned. But perhaps that's for a different use case than you're working with.