Pawel Piotrowski

Unfortunately not. FMX applications are totally not accessible under android/iOS. At least when I last tested. The screenreader support for windows is also not perfect. The control under the mouse is often not read aloud and sometimes changing the focus to a new control also is not announced. In VCL applications there is also a problem, that none of the graphic controls like TLabel or TSpeedbutton are "seen" by a screenreader. Which is no wonder, since they do not have a underlying window control with a proper handle.

I had a look into my old code. To mitigate the need to show the tab I called WebBrowser1.HandleNeeded; before the call to WebBrowser1.Navigate

What was the problem with StackOverflow ? Just curious. as for the invisible browser, I had a similar problem with the old TWebBrowser in a hidden TTabsheet on a visible TForm. I needed to show it at least once. I don't know the exact reason, but it seems it requires some message to be send to the web browser, before it will work properly. Try showing the form and then hiding it... if it works, then try to pin-point the windows message that it requires to start going. If you know it, then you can emulate it. I know, that is not a ready solution, but maybe that helps a bit.

Grijjy is also my favorite. Easy to use and quite fast.

Usually I put as much as possible in svn. We have even some projects where we put the executables and dll files and all the files needed for a deployment into the svn. That is great because a tester can just update his working copy and test the newest build. Or he can go back and tell us when a bug was introduced. For the team it is also great. No need to sync images, dlls, configs or other data through some other tool. Just Update your working copy and you are good to continue your development. If you are worrying about the repository size on the server, remember that SVN stores delta files even for binary files. Maybe not as gracefully as for real text files, but disk space is much cheaper then developer time.

Actually, your code is wrong. Now you are doubling the memory usage. SetLength creates a big string, then in the loop, you add more to it... If you wish to pre-allocate the length of the string, then you need to do it this way: Function MultiplyStrWithPreallocate(aStr: String; aMultiplier: Integer): String; Var i, pos: Integer; Begin SetLength(Result, Length(aStr) * aMultiplier); pos := 1; For i := 1 To aMultiplier Do Begin move(aStr[1], Result[pos], Length(aStr) * sizeOf(Char)); Inc(pos, Length(aStr)); End; End; Here is what is going on behind the scene, when you call: Result := Result + aStr; the memory manager creates a new temporary string, assigns the content of "result" and "aStr" to it. That new temporary Strings is then assigned to "result" which in turn decreases the reference counter to the String that result is refering... in that case to 0, which causes the memory manager to release that String. So for a short period of time, both, the original "result" and the "result"+"aStr" are in memory. And for each for-loop-iteration, you basically have a copy operation of the whole string. My above optimization using move reduces both of those concerns. There is just one memory allocation, and only a few bytes are copied in each for-loop-iteration

if you are more comfortable using strings, then just use rawByteString. TBytes are fine, too. There will be no real performance drawback using them. RawByteString have a possible drawback, depending how you will use them. There are some functions, that expect a string, but will happyly accept a rawByteString, doing a implicit conversion. And that conversion from rawByteString to String and then back to rawByteString can cost some performance... You will not have such a problem with TBytes. SO if you go with rawByteString, keep a close look on your compiler warnings 🙂

The copy on write rule is only for strings. Arrays are reference counted and that's it. If you need to copy the content of the array, you need to use the copy() function. It will create a new instance of your array.

Maybe have a look at the DEB an Event Bus framework for Delphi from Daniele Spinetti. I think you will like it. It should help you achieve your decoupling without too much added complexity. here is the blog entry about this: http://www.danielespinetti.it/2016/02/deb-event-bus-framework-for-delphi.html and here the git repo: https://github.com/spinettaro/delphi-event-bus

I suppose I would write a power point automation. You can control Word and Excel with delphi I suppose you could control power point as well. From there it is simple and fast. Insert your text/music/images into your ppt a template then let power point export it as a video file.

Good or bad memory doesn't matter. You need to be able to navigate and understand the code even if you didn't wrote it yourself. I would guess, your biggest problem lays in the hard to find coupling of controls with the actual code. In other words, bad code navigation capabilities. Code navigation is for me personally more important then separation. Well, I know, controversial. And don't get me wrong, I'm all for separation, but try to find a way, that allows you to navigate your code nicely and have still your separation. When you have a dozen of projects, each with hundreds of units... well, you will be thankful to be able to navigate the code with ease. Do not try to follow the hype just because. There should be a reason to do it. Over complicating things doesn't solve anything. You wrote, that your mainform references the frame, maybe it shouldn't? Maybe it should reference the presentation layer instead. Maybe you should couple the frame with that presentation layer there, or at least have a call to the coupling there? I know the unpleasant WTF moment, when you look at a form, and have no idea where the code is, that supposed to be there... then you go on a search, wasting a lot of time...just because someone decided to implement a fully decoupled system just for the sake of it. I would suggest two solutions: 1. Hide the frame from yourself. the mainform (or better said, your entry point) should reference the presentation layer, where you can find the coupling of the controls and the frame that is used. or.. 2. let the frame couple itself with the presentation layer. There is something beautiful to be able to click in the form designer on a button and see where the call goes. You need to do the coupling somewhere anyway. There is little reason to remove *all* the code from the frame. And if you do that, ask yourself what is the real benefit for you. Are you solving a problem or are you introducing one?

I agree. But others before me pointed that already out 🙂 I was trying to explain (not justify) the differences between the two samples given, the one with 17% more memory and the second with 68% more. You can explain the +17% with the missing SetLength, but not the +68% more memory. More knowledge doesn't hurt, and if someone uses the task manager to compare memory usage, I suppose it is nice to know about the memory manager itself, isn't it?

Like others said, TList has a capacity growing strategy. The second, and more important thing is, that the memory manager doesn't release the memory back to windows. So what you might getting is this: when you add items to the list, and it tries to resize, it might happen, that there is not sufficient memory in the current place to just in place resize. so the memory manager copies the whole array to a new location, that can hold the size of the new array. but the old memory space is still kept reserved by the memory manager. So when you use the task manager, windows sees both. Andd BTW, the memory manager doesn't request the exact size either. Like TList, it has a growth strategy, too.

Thanks 🙂 The answer to your question is yes and no 😉 No: not with the default Delphi settings and not in a regular record or class, no a word can not cross 32bit boundaries. The compiler ensures that for you by default. Yes: You can force it to cross the 32bit boundaries. Delphi gives you this option. Like with packed records. Or by changing the compiler settings, or by using the compiler directive... and maybe something else 😉 But that is usually a conscious choice.

I might unintentionally confused you... sorry for that. The header in my test saying "aligned" should rather say "starts with memory divisible by 4". But that was too long for the header. I tried - and failed it seems 😉 - to clarified that at the bottom of that same post. even if a variable doesn't start right away aligned (so its memory allocation is not divisible by 4), but doesn't cross the 32bit boundary, it is guaranteed to be atomic. Basically, a word is atomic, no matter if the 2 bytes that have to be discarded are at the start of the memory or at the end of it.