Leaderboard

Stack Overflow has a good system with casting flags where certain amount of flags automatically deletes the post. Flags are available based on reputation to prevent abuse and bad flags cause flagging suspension. Also moderators can issue manual suspension. Because we are small forum, you could even manually give such delete flag capabilities to trusted users where you know they will not be abused and automatically delete posts even with single flag. There is enough of us to keep the site clean, the only thing needed is infrastructure that would allow that.

here

This problem is always going to be with us. But we do need to keep the forum open. New members = new blood = new ideas. Without new members the forum has signed it's own death warrant (even if it is a slow death).

Delphi pulls the account info from XCode via PAServer, so if XCode can handle several accounts, then Delphi can do it too. Yes, to have different developer accounts works for me, but you have to take care that you switch all provisioning profiles and BundleID's correctly. To have even one account can be enerving enough, but that not a Delphi issue, it comes from the Apple side.

Unethical? Really? Funny how we would never expect such a thing for physical media. Try going back to where you bought a Blu-ray and demand a free replacement because you lost the one you bought a year ago. I figure any time I am buying software, if they offer me a maintenance subscription and I turn it down, I am going to be on my own when the initial support period is up. I have a drive full of software setup packages so I don't have to hope someone else is storing my data for me.

I wonder where @RRUZ got this unit. IF we are talking about the same component, according to it, TEditControl has two published properties: property CaretX: SmallInt; property CaretY: Integer; If we can find out how to access this type from a Delphi application (even without source) I'm sure TEditControl could be accessed via it's handle and some pointer magic...

I don't think this will work as the editor control (TEditControl) does not descend from TEdit or TMemo but from TWinControl (via TCustomControl -> TCustomEditControl): But I might be wrong, maybe one of those controls processes this message. Edit: TMemo descends from TCustomEdit (which itself descends from TWinControl), not from TCustomEditControl.

Tested in 10.3.3 and 11.3 - works in both of them. Update: Works also in 10.2.3, but fails in 10.1.2

Count me in as a volunteer too, if needed.

And here I thought the chatgpt hype died down already. Got proven wrong yet again 🙂

To open a file you can use DDE, which @Attila Kovacs got working some time ago: As for repositioning, you can try to get the handle of the editor control and send a EM_SETSEL message. That would be my approach, that is.

I'm volunteer.

I will have to change my position. I was focused on behavior where compiler would catch all cases where record would be uninitialized - by all I don't mean having different code paths where compiler cannot easily determine whether something is initialized or not even for types it currently shows warnings. To catch all such cases, calling record method would also need to show a warning, but there is no way compiler can differentiate between method that initializes a record and method that expects already initialized method - the difference between imagined TGuid.Clear and TGUID.IsEmpty. However, for other value types calling a method does not trigger a warning and simply disables further warnings, so such behavior could be easily extended to non-managed fields in records without causing any bogus warnings and would not be any more difficult to achieve than existing warnings for other value types. It is likely that variant parts in records would have to be excluded as accessing and initializing one field does not mean that another field that shares same memory would be fully initialized (memory overlap can be only partial) and it is possible that tracking sizes and what is initialized and what not would be too much in such scenario. There is a value in showing at least some warnings comparing to none.

You can still assign individual shortcuts to "Grep Search" and "Grep Results", and there is no need to assign a shortcut to "Grep" (the submenu). In fact that's the default. And for me it works the same way as it always has.

We already have the situation that calling any method on a record disables the warning - I did not mention disabling that behavior, did I? Also, don't you think a compiler could easily see if the access to a field happens before or after some method call? I explicitly stated that there would still be cases where a W1036 would be appropriate but would not be seen due to some reasons but in the places where it is hundred percent certain that the access is to an uninitialized field the compiler should raise it

To be "Musked" I believe it's called

https://github.com/kami-soft/ProtoBufGenerator

Sectigo and any Sectigo resellers supply YubiKey's Digicert supply Safenet tokens No reply from the other CA's I have contacted so far. FYI - Safenet good (can automate), YubiKey bad (password prompts cannot be avoided).

How about the pro-active approach ? This should have a huge, preventive effect against SPAM

Like a torrent forum, invite only 😉

First question : Is this supposed to be a FMX or a VCL program ? If FMX you can write this app with "no code" (except itemclick to change from list to view and reverse) using Livebindings Here a french tuturial I wrote (2018)