Remy Lebeau

Your formatting is all messed up, please fix it.

Why does your device manager keep refreshing and showing the port disappearing? Are you perhaps opening the port during the time it has disappeared? What does your code look like that is opening the port?

Look for the tfVerificationFlagChecked flag in the TTaskDialog.Flags property after TTaskDialog.Execute() returns true: if TaskDialog.Execute then begin ... Result.DoNotShowAgain := tfVerificationFlagChecked in TaskDialog.Flags; ... end And, if you want the checkbox to be initially checked when you display the dialog, enable the tfVerificationFlagChecked flag before calling TTaskDialog.Execute(): TaskDialog.Flags := [tfUseCommandLinks, tfAllowDialogCancellation, tfExpandFooterArea]; if DoNotShowAgainIsChecked then TaskDialog.Flags := TaskDialog.Flags + [tfVerificationFlagChecked];

You can configure the IDE to not break on exceptions. I usually use breakpoints to tell the debugger to not break on exceptions that occur within specific sections of code I don't want to break on.

The information you are looking for is not compiled into the EXE/DLL itself. Tools like IDR exist to heuristically analyze an EXE/DLL and compare its signature to a database of known compiler versions. How to detect Delphi compiler version in which exe was compiled?

If the code is expecting a debugger to attach, I would just call IsDebuggerPresent() in a sleep loop until it returns true or times out.

You can't, as there is no way to get from the MenuHandle/HMENU to its dialog window. However, there can only be 1 menu active at a time, so you should be able to use FindWindow/Ex() to find the HWND of the active menu whose window class name is "#32768"/MAKEINTATOM(0x8000), Once you have the menu's HWND, you should be able to use GetWindowRect() to get its position and size.

You can't have the 11.3 CE and 11.3 full versions installed on the same machine at the same time. This is stated in the FAQs. So you will have to uninstall 11.3 CE before installing 11.3 full. Otherwise, you can install the 12.x full version alongside the 11.3 CE version.

Sorry, I don't have any examples to give you, as I don't write code for Android.

You did not show the code that receives the file path from the file chooser and puts it into the TEdit, or show what the file path actually looks like. But ACTION_GET_CONTENT is documented as returning a "content:" uri, which requires you to use the ContentResolver class to access the file data. But TIdMultipartFormDataStream.AddFile() uses TFileStream, which wants direct access to the file, which will not work with a "content:" uri on modern Android versions. So you will likely have to either: access the file yourself via Android APIs and read its byte data into a TMemoryStream or TByteStream, or create a custom TStream that wraps an Android InputStream from the ContentResolver.openInputStream() method And then use TIdMultipartFormDataStream.AddFormField() instead of TIdMultipartFormDataStream.AddFile() to send whichever TStream you end up using. Alternatively, you can use ContentResolver to extract the underlying "file:" uri from a "content:" uri, and then you should be able to open the file using a normal TFileStream (provided you have permissions to the file). Also, when using ACTION_GET_CONTENT, the ACTION_GET_CONTENT documentation says to wrap your Intent with Intent.createChooser(), and also include CATEGORY_OPENABLE and FLAG_GRANT_READ_URI_PERMISSION on your Intent.

Can to elaborate further? What is the actual error that you are getting? Note that TApplication.MessageBox() is generally just a wrapper for Winapi.MessageBox(). Although it is not entirely thread-safe, as it manipulates a global TaskActiveWindow list. So yes, using Winapi.MessageBox() directly is generally safer when displaying a message box in a worker thread.

That's a contradiction. Either you have the permissions or you don't. What does your code look like that is asking the user for permission to access the file, and the code that tries to upload the file?

Just because the Labels are disabled does not mean the Panel will handle mouse activity when over them. You are still mousing over the Labels, so you need to catch and forward the event activity from the Labels if you want to handle them the same as events on the Panel. Otherwise, you can subclass the Panel to handle the underlying mouse messages before they get dispatched to children. Since the Panel is a windowed control and the Labels are graphical controls, the Panel is the one receiving the messages from the OS and passing them along to the Labels.

You say you have hundreds of TComboBoxes, but the screenshot above only shows 7 (presumably 11?). If this screen is similar for the rest of the app, where each item on the side list displays its own page with just a handful of ComboBoxes on it, then a simple solution would be to NOT load every page at one time, but instead to load one page at a time only when it is made visible to the user, and then unload it when it is no longer visible to the user. That will greatly speed up your load times, and then you don't have to resort to using hacks like owner-drawing, OnDropDown refreshes, etc. You can move each page to its own TFrame that you create and destroy when needed, that way you still regain design-time support for your page layout.

Getit has not been restored for versions prior to RAD Studio 12.0 Athens yet.

Some suggestions: don't use WM_SETREDRAW directly. Use the TComboBox.Items.(Begin|End)Update() instead, which will use WM_SETREDRAW internally for you. CB_INITSTORAGE helps, but simply don't waste time putting actual string values in so many TComboBoxes to begin with. Instead, fill them with blank strings, and set their Style property to csOwnerDrawFixed and use their OnDrawItem event to render the actual text whenever a drop-down list is visible. consider using a different UI control, such as a TListBox, or a TListView in vsReport mode. Both have true virtual modes that can handle a lot of items very quickly.

Indy does not implement RFC 6854 (I didn't even know that existed). It does implement 822/2822, but I don't recall to what extent it implements 5322 (perhaps just aspects of it?). Most likely, yes, as long as you don't need to use some modern email features, like signing, etc. If you run into problems, let me know. Do be aware that, by default, TIdMessage saves its data to a TStream/file using a dot-transparency format (ie, lines that begin with a period are escaped with an extra period) that is intended for use with the SMTP and POP3 protocols but not with other protocols. So, you will likely need to utilize the class helper in the IdMessageHelper unit, which adds an AUsesDotTransparency parameter to the TIdMessage.SaveTo...() methods, then you can set that parameter to False.

CW_USEDEFAULT is actually typed as 'int' in the Windows SDK (in winuser.h): #define CW_USEDEFAULT ((int)0x80000000)

Indy allows that just fine - provided you adequately serialize access to the socket to avoid multiple threads overlapping their outgoing packets. Although multiple threads CAN send to the same socket provided they don't overlap, it is generally a better idea to handle all of the sends in a single thread instead.

IMHO, just because the constant was DWord doesn't mean the variables should have been DWord.

Did you setup your Connection Profile(s) for the target debugger(s) before invoking the "Attach to Process" dialog?

Oh. I didn't realize that was you.

I was referring to this code: Why were nLeft, etc declared as DWord to begin with and not as Integer, as the Win32 API expects?

Why were your variables declared as DWORD to begin with? The Win32 API represents window positions and sizes as ints, not as dwords.

Which issue is that?