Dalija Prasnikar

It doesn't help much. The code does not make sense, so it is very hard to understand what you want to accomplish and even more importantly why. Delphi does support background threads on mobile devices, but again your code is very much wrong. Again, don't ever call ExecuteWork on task, use Start. It would help if you could show your original code as in what you need to do, without your broken solution which just makes it harder to understand what you need.

I don't quite understand what you mean that it didn't wait until task complete, but you are using the task wrong. First, you should never call ExecuteWork as it is internal method. You should use Start instead. Next code within task procedure will run in the background thread so when you call fTask.Start any code following that line will immediately run and it will not wait for task completion. The whole point of running a task is that it does not block further code along with the GUI. Next, since task procedure will run in background thread, you must never call Application.ProcessMessages within, because it can only be called within main thread context. And because task is running in the background you don't need to manually pump message queue anyway. If you wanted to use it to simulate some work, just use some other code. If you want to wait for task to complete you can call fTask.Wait, but this will then block the thread were it is called and if you call it on main thread it will block the main thread which defeats the purpose of running a task in the background. It only makes sense if user closes some form or similar and you need to wait for task to perform some cleanup. But in such scenarios you need to know that wait will be very short or you will get unresponsive application.

Maybe. But do you have proof that this is so. Do you have any proof that women like programming as much as men? If there are no gender differences then there should be way more women programmers than they are now. The percentage is just way to low that discrimination could be the only reason.

Because, even after initial selection in elementary school (where boys girls ration was 50:50) I was the only girl that went into tech oriented school, others went into social sciences or biology/chemistry/medicine. And then in high school there were more boys than girls from the beginning, where some classes were all boys and the rest were again 50:50. And from those 50:50 split classes (I think there was around 80 girls total), I was the only girl that pursued programming. And again, it was not that other girls couldn't code at all, but they were just not interested. I was the only one that spent nights behind the computer. Of course, there could be other factors, but I am pretty sure that in general women are just less attracted to coding than men. Again, I am not saying that they cannot do it, just that they are less attracted to such jobs. And again, I grew up in society that didn't have any obstacles for girls and women when choosing careers during education. I don't know if something changed in the meantime, but I doubt as my kids never reported that girls are having different treatment (and I asked them).

I have no problem with women plumbers, electricians, engineers, even astronauts (depending on a mission). But I would definitely draw the line with fighter pilots, or fire fighters and similar. The physical failure in critical moment can cost lives and not just theirs. We have to be real. There are plenty of jobs where physical fitness is required, but it is not absolutely critical. There are some jobs where it is. And again it is not that women couldn't do it, or that women shouldn't do it if there are no better fit men for the job, but I see equality being pushed in places where there is no place for it and where it could be dangerous because exceptional circumstances are part of the job and where physical strength is vital.

Well, I am pretty sure that women are less interested in coding in general. I have seen that both in my math-tech oriented high school and in math university. There were enough women there (even more in the university - about 40-50 %) and they were good in math (usually even better than men), but I was the only one in my generation (even several generations) that liked coding. Others all went into different directions. In high school everyone would come to me to help them with coding problems as I knew the most, almost my math and informatics teachers were women (only one man and he was the least competent one). So definitely there was no environmental pressure that would keep us away and I have never heard that girls or women cannot do math or code or anything like that.

I am sorry, but that is just not true. Women are generally physically weaker than men of same constitution and weight. I am talking about muscle strength, lung capacity, stamina. Again, I am not saying that there are no women that could work in some extreme conditions, but I think this is the wrong place to push equality. Imagine an accident in the mine, where men would be in better position to survive and also to help others.

Yes, there are definitely some jobs that are not meant for women. I am not saying that there are no women that can endure it, but in general jobs that require physical strength and stamina are not a good fit for women. It is a safety issue as they can more easily get hurt and could lack strength in critical moments and it is not just about them as there may be situations where others working with them can get hurt, too.

They just tried that and it was complete disaster https://meta.stackoverflow.com/questions/425162/we-are-seeking-functional-feedback-for-the-formatting-assistant

Probably rather low. Maybe a handful, unless we count all the Italian guys named Andrea and Danielle as women, too (PS those names are female in Croatia and it took me a while to find they are male names in Italy)

I am not questioning the number, but the explanation is moot. I have noticed that US folks (companies) have some strange desire to treat anyone outside of white male group as some sort of victims, which is both insulting and is not based in reality. I don't know, maybe women in US feel differently, but again, that has nothing to do with SO and moderation, but general culture. I have noticed that some people try to play victim card purely because it will give them advantage, and maybe some even think that is so, but that is something they need to fix on personal level. Also one of the explanations for low participation of women on SO is that they are afraid, but maybe they are just more thorough in their research and are better in solving problems on their own. I certainly used SO for years before I joined, but not because I was afraid, but simply because I didn't have the need to ask any questions. And when I joined I did that because I wanted to leave comment under one question about some high DPI bug, but then I needed 50 rep to do that, so I started answering... Point is, that anything is possible and it depends on each individual. Painting everyone with the same brush based on some completely unrelated characteristic is pure nonsense.

That is complete nonsense. Company loves analyzing their surveys by skewing context and seeing things that are not there. There is no barrier for entry for anyone based on who they are. Anyone can be as anonymous as they like or present themselves as they please. There are moderators with names UserXXXX.

I have no idea what you are trying to say.

Don't give them more bad ideas. It is not that AI cannot be used for moderation, but at this point I am pretty sure it will be used in wrong way.

The whole situation at Stack Overflow just made a drastic turn for the worse: https://meta.stackoverflow.com/questions/425162/we-are-seeking-functional-feedback-for-the-formatting-assistant and https://meta.stackoverflow.com/questions/425081/stack-overflow-will-be-experimenting-with-a-question-formatting-assistant-and-w It seems that whole reason behind tying the mods hands when it comes to detecting and moderating AI content is related to the brand new "AI Formatting Assistant" It is presented as something that would help people write better questions, but I guess that is just first step and second one would be expanding it to answers, too. Because such "formatted" posts would have typical AI signature, moderators would not be able to distinguish between AI generated and "merely formatted" posts. Additionally, the results of "formatting" go beyond mere formatting because AI completely rewrites the post including text and code adding its hallucinations on top. It is beyond horrible and harmful.

Strike update: https://meta.stackexchange.com/questions/390106/moderation-strike-update-data-dumps-choosing-representatives-gpt-data-and-wh

The problem is that all variants of IGenericList<T> have same GUID so Supports function will succeed even though those different generic lists are not compatible.

There is not bug in compiler, but in your code. When you say LCastedList.Add(TAncestorObject.Create) What will happen is equivalent of following code: var Tmp: IInterface := TAncestorObject.Create; LCastedList.Add(Tmp); This will be because LCastedList is declared as IGenericList<IInterface> and stores IInterface references. However when you retrieve stored reference you will call that on original list which is declared as IGenericList<IAncestorObject> and retrieved reference will be of type IAncestorObject and you can try to call LObj.ID on that retrieved reference. But in reality stored reference was IInterface, not IAncestorObject and it crashes when you call ID on it because that method (GetID) it simply does not exist there. Point of generics is that you have same type stored in the background, not to store incompatible types. even though there is same object behind those two interface references, those interfaces are completely different types represent different entry points to that object. Sometimes you can force "wrong" type to be stored at runtime, which is usually not what you should be doing, but if you do, you need to make sure that every time you retrieve something that might be "wrong" you cast it back to appropriate type. var LTmp := LList.First; var LObj: IAncestorObject; if Supports(LTmp, IAncestorObject, LObj) then var LID := LObj.ID ;

LSP is separate process and it's memory consumption does no affect the IDE. Extracting that functionality outside and reducing IDE memory footprint was one of the reasons LSP was introduced in the first place. There is known GDI handle leak in Parnassus Navigator https://quality.embarcadero.com/browse/RSP-40986 Also IDE is using a bit more GDI handles than it used to and it seems that it has some caching issues, where it caches the component icons but it does not have a cache limit and it does not release those that were not accessed in for some period of time. Opening plenty of forms and accessing many different components during design time can hit GDI handle limit. AFAIK you can increase that limit (I never had issues so I never tried it) https://stackoverflow.com/questions/38612364/how-to-increase-the-maximum-amount-of-gdi-object-for-windows-10

Yes, but you don't get there by self appointing yourself, either.

Strike has officially started https://meta.stackexchange.com/questions/389811/moderation-strike-stack-overflow-inc-cannot-consistently-ignore-mistreat-an

Be careful what you wish for, as you may actually get it.

No worries. I am glad you were able to resolve the issue.

If that is the requirement, then, yes, setting global FormatSettings variable will have that effect. You also need to change Application.UpdateFormatSettings to false, before you change global FormatSettings to avoid user changes to be applied if the application is already running. You also need to keep in mind that any code that does not use global FormatSettings will not be affected by changes in global variable. For instance Delphi JSON serialization uses fixed settings for serialization that are based on JSON format requirements. Any code that uses own settings will behave in similar way. I would still suggest that for serialization purpose and data persistence, you use separate FormatSettings variable as if (and when) specification changes and users are allowed to have their preferer format used for viewing purposes, it will be very hard to make separation afterwards and find all the places that need to use specific fixed format.

No. If you say var FormatSettings ... you will declare new FormatSettingsVariable in the scope where you have written that code, that will have nothing to do with global FormatSettings variable. If you want to change the value of global FormatSettings variable you need to write FormatSettings := TFormatSettings.Create('en-AU') However, changing global FormatSettings variable is not advisable for several reasons: 1. FormatSettinsg is populated with user's locale. You should honor the user settings and present data to the user in format user has specified, not the one you think it should be. 2. If user changes locale settings while your application is running, those new settings will be applied to the global FormatSettings variable if the Application.UpdateFormatSettings is True (which it is by default) 3. FormatSettings beging a global variable are not thread-safe and if any other code changes those settings (and there has been such code out in the wild) and code running in threads that uses the global will be affected. Using formatting and parsing routines that use FormatSettings passed as additional parameter is the best choice for avoiding thread-safety and other issues as you will have the control over which settings are being used. 4. And the most important aspect, if you have code that relies on very specific values in FormatSettings, like serialization, should not depend on global FormatSettings variable but should have its own more scoped (and therefore more protected) TFormatSettings variable that will be set once and never change during the application lifetime. Using global FormatSettings for working with data that needs to be in some specific format is the fastest way to shoot yourself in the foot. No, you should not forget about it for reasons I specified above. Any formatting and parsing function that uses global FormatSettings variable will be affected by the change in global FormatSettings whether you change it or some other code. Yes. If you use functions that rely on global variable, they will use whatever value at the time is in that global variable.