delphi-xe4

CharInSet Compiler Warning in Delphi XE4

本秂侑毒 提交于 2019-12-03 13:33:55
问题 I have following statement in my Delphi 7 code. TMyCharSet = set of char; When I migrated that code to Delphi XE4, I am getting following compiler warning at above line. W1050 WideChar reduced to byte char in set expressions. Consider using 'CharInSet' function in 'SysUtils' unit. How should I redeclare TMyCharSet? 回答1: You get the warning because XE4 uses WideChar for variable of Char type (and WideString for String), so Char takes 2 bytes instead of 1 byte now. Now it is possible to keep

Delphi Unicode String Length in Bytes

折月煮酒 提交于 2019-12-03 12:05:12
I'm working on porting some Delphi 7 code to XE4, so, unicode is the subject here. I have a method where a string gets written to a TMemoryStream, so according to this embarcadero article , I should multiply the length of the string (in characters) times the size of the Char type to get the length in bytes that is needed for the length (in bytes) parameter to WriteBuffer. so before: rawHtml : string; //AnsiString ... memorystream1.WriteBuffer(Pointer(rawHtml)^, Length(rawHtml); after: rawHtml : string; //UnicodeString ... memorystream1.WriteBuffer(Pointer(rawHtml)^, Length(rawHtml)* SizeOf

CharInSet Compiler Warning in Delphi XE4

半腔热情 提交于 2019-12-03 03:38:44
I have following statement in my Delphi 7 code. TMyCharSet = set of char; When I migrated that code to Delphi XE4, I am getting following compiler warning at above line. W1050 WideChar reduced to byte char in set expressions. Consider using 'CharInSet' function in 'SysUtils' unit. How should I redeclare TMyCharSet? Andrei Galatyn You get the warning because XE4 uses WideChar for variable of Char type (and WideString for String), so Char takes 2 bytes instead of 1 byte now. Now it is possible to keep unicode characters in String/Char, but for same reason it is impossible to use set of char

Delphi XE4 immutable strings

自古美人都是妖i 提交于 2019-12-03 01:54:24
With Delphi XE4 for the iOS platform a new string type was introduced: Immutable zero based strings. So far Delphi had copy on write mutable strings. So the question is, what does that mean for my future programming? Are there any advantages of one string type over the other? What are the pitfalls I need to take care of when switching to the new string type (Other than the obvious 0 vs 1 base)? David Heffernan According to Marco Cantù's whitepaper , the string data type in the XE4 iOS target is not in fact immutable, although he seems to contradict himself. He says: In the new Delphi LLVM

Delphi Interface Reference Counting

£可爱£侵袭症+ 提交于 2019-12-02 22:57:37
I ran into a strange situation while testing something today. I have a number of interfaces and objects. The code looks like this: IInterfaceZ = interface(IInterface) ['{DA003999-ADA2-47ED-A1E0-2572A00B6D75}'] procedure DoSomething; end; IInterfaceY = interface(IInterface) ['{55BF8A92-FCE4-447D-B58B-26CD9B344EA7}'] procedure DoNothing; end; TObjectB = class(TInterfacedObject, IInterfaceZ) procedure DoSomething; end; TObjectC = class(TInterfacedObject, IInterfaceY) public FTest: string; procedure DoNothing; end; TObjectA = class(TInterfacedObject, IInterfaceZ, IInterfaceY) private FInterfaceB:

JvMail (JEDI) component not sending mail

喜你入骨 提交于 2019-12-02 08:22:06
JvMail component is not functioning right or I am messing something up. procedure TForm1.RzURLLabel1Click(Sender: TObject); begin if cxLookUpComboBox1.Text ='' then abort else with JvMail1.SimpleMAPI do begin JvMail1.Clear; JvMail1.Recipient.AddRecipient('smtp:mymail@gmail.com'); JvMail1.Subject := 'Password lost '; JvMail1.Body.Text := 'Request password :' +#13#10+ cxLookUpComboBox1.Text +#13#10+ AdvOfficeStatusBar1.Panels[4].Text ; JvMail1.SendMail; end end; My mail does not get sent unless I put the prefix 'smtp:' infront of the mail adress. Any ideas on how to fix this ? Sir Rufo The

OmniThreadLibrary - Code: 1816. Not enough quota is available to process this command

我怕爱的太早我们不能终老 提交于 2019-12-01 20:16:25
问题 Update 1 : I included the stack traces of all threads instead of just the main thread's - I thought it was enough already. Update 2 : I reopened this question, since even after applied the changes illustrated in my own question, I still get the very same error report today... Update 3 : It seems that the error happened when the thread is terminating and the thread message that's being sent when the error happened was COmniTaskMsg_Terminated . Now it's very strange - I've replaced almost all

Does interface delegation of an inherited interface require a wrapper class?

人走茶凉 提交于 2019-12-01 20:05:20
Delphi allows for interface delegation using the implements keyword. For example IIndep1 = interface function foo2: integer; end; IIndep2 = interface function goo2: integer; end; TIndep1And2 = class(TInterfacedObject, IIndep1, IIndep2) private FNested : IIndep1; //e.g. passed via constructor or internally created (not shown here) public Constructor Create(AIndep1: IIndep1); function goo2: integer; property AsIndep1 : IIndep1 read FNested implements IIndep1; end; That works well, but not for inherited interfaces. (Error message "Missing implementation of interface method ILev1.foo") ILev1 =

Why is OmniThreadLibrary's ForEach blocking main thread?

丶灬走出姿态 提交于 2019-12-01 00:19:51
Using the OmniThreadLibrary and Delphi XE4, I am hoping to run multiple threads that process data in the background, adding speed increases to my already existing code. When calling the procedure below, the Application GUI stops processing any input until all of the threads have completed. My understanding is that using .NoWait should allow the procedure to exit even when the threads are running. procedure Test(input: TStringList; output: TList<TMaintFore>); var outQueue: IOmniBlockingCollection; transaction: TOmniValue; begin outQueue := TOmniBlockingCollection.Create; Parallel.ForEach(0,

Why is OmniThreadLibrary's ForEach blocking main thread?

倖福魔咒の 提交于 2019-11-30 19:13:17
问题 Using the OmniThreadLibrary and Delphi XE4, I am hoping to run multiple threads that process data in the background, adding speed increases to my already existing code. When calling the procedure below, the Application GUI stops processing any input until all of the threads have completed. My understanding is that using .NoWait should allow the procedure to exit even when the threads are running. procedure Test(input: TStringList; output: TList<TMaintFore>); var outQueue: