pyscripter

An alternative to the method Žarko Gajić described is the following code: function ScaleImageList(Source: TCustomImageList; M, D: Integer): TCustomImageList; const ANDbits: array[0..2*16-1] of Byte = ($FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF, $FF,$FF); XORbits: array[0..2*16-1] of Byte = ($00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00, $00,$00); var I: integer; Icon: HIcon; begin Result := TCustomImageList.CreateSize(MulDiv(Source.Width, M, D), MulDiv(Source.Height, M, D)); if M = D then begin Result.Assign(Source); Exit; end; Result.ColorDepth := cd32Bit; Result.DrawingStyle := Source.DrawingStyle; Result.BkColor := Source.BkColor; Result.BlendColor := Source.BlendColor; for I := 0 to Source.Count-1 do begin Icon := ImageList_GetIcon(Source.Handle, I, LR_DEFAULTCOLOR); if Icon = 0 then begin Icon := CreateIcon(hInstance,16,16,1,1,@ANDbits,@XORbits); end; ImageList_AddIcon(Result.Handle, Icon); DestroyIcon(Icon); end; end; It is simpler and I think works better.

@Anders Melander You are using an old version of SynEdit. The key difference is the calls to UnionRect in TCustomSynEdit.InvalidateLines. Please compare to the SynEdit master branch. The difference is subtle, but in effect in your version any character entry invalidates the whole Window and this why you PaintTransient works. UnionRect(fInvalidateRect, fInvalidateRect, rcInval) is not the same as UnionRect(fInvalidateRect, rcInval, fInvalidateRect)! when fInvalidateRect is empty!

Another issue with your code is that since you are using TArray.BinarySearch your bracket array needs to be sorted. But OCSYMBOLS: Array[0..7] Of Char = ('(', ')', '{', '}', '[', ']', '<', '>'); is not.

By the way in the code above: a := SynEdit1.RowColToCharIndex(bufcoord); followed by c := SynEdit1.Text[a]; in fact twice, is not efficient. You are better-off just using c := SynEdit1.Lines[bufcoord.Line][bufcoord.Char]

Anders is probably not using TurboPack SynEdit. His version of SynEdit is not handling ttBefore painting and the only way this can work is if SynEdit invalidates everything every time a character is typed. Turbopack SynEdit painting has been optimized to avoid flicker, so his version of Bracket Highlighting will not work with Turbopack SynEdit. I have committed some changes to Turbopack SynEdit (see Matching brackets highlighting with PaintTransient handler error · Issue #110 · TurboPack/SynEdit (github.com)). Could you please try with the latest version and see whether it now works correctly?

By the way, this is a good way to expose Com objects to python without relying on PyWin32.

I think the above should work. Have you enabled the generation of RTTI in your project? Does adding {$M+} help like in: {$M+} ITestInterface = interface(IInterface) ['{AD50ADF2-2691-47CA-80AB-07AF1EDA8C89}'] procedure SetString(const S: string); function GetString: string; end; {$M-}

Toolbar images are not scaled but otherwise looks good!

I am afraid the download link does not work.

You can use TPyDelphiWrapper.WrapInterface to wrap interfaces. Have a look at Tests/WrapDelphiTest.pas to see how this works. Alternatively the PyWin32 python module has its own way of wrapping Com objects.

Are you talking about code completion in the editor or the interpreter? If it is in the editor does it help to add you delphi module to Tools, Options, IDE Options, Code Competion, Special packages? You need to restart PyScripter or the Language server. The other thing you could is to create a stub file for your python extension module (see for instance PyScripter: Completion with python extension modules such as PyQt5 and Pandas).

Have a look at the routines in SVGIconImageList/SVGCommon.pas at master · EtheaDev/SVGIconImageList (github.com) (GetExtended in the implementation section). They were "stolen" from synopse/mORMot: Synopse mORMot ORM/SOA/MVC framework (github.com) and they did make a big difference when parsing SVG files.

I think yes after the fix discussed in this thread.

The Spring4D is the best. If you use Spring4D stick to it.

Is anybody using the Asynchronous Programming Library? AFAICT, it works like TThread.Synchronize/Queue/ForceQueue, but it gives you greater control on the tasks executed asynchronously. (Cancel, Wait etc.) TComponent.BeginInvoke(procedure begin end, nil).Invoke just uses TThread.Queue. TWinControl.BeginInvoke(procedure begin end, nil).Invoke processes the procedure in the event loop of the WinControl. Are there any examples of usage?

IAsyncResult is a higher level of abstraction than PPL. You want the async backend to be TThread.Queue, Anonymous Threads, PPL, OmniThread, processing in a message loop, all you have to do is overwrite one method. I would argue that debugging any asynchronous application is kind of hard to put it mildly.

@Vincent Parrett@Dalija PrasnikarI was also quick to dismiss it and I disliked the fact that the functionality is under TComponent. However, after a bit of digging it appears that it does have some nice touches. For example TComponent, uses Thread.Queue to run the tasks and WinControl uses the message loop. But a component descendent can overwrite just one method AsyncSchedule to use the Parallel Libary or OmniThread to run the tasks, e.g.. // Disclaimer: Have not tested! type TPPLComp = class(TComponent) protected procedure AsyncSchedule(const ASyncResult: TBaseAsyncResult); override; end; procedure TPPLComp.AsyncSchedule(const ASyncResult: TBaseAsyncResult); var LState: TComponentState; begin LState := FComponentState; // Snag a local copy if csDestroying in LState then raise EInvalidOperation.CreateRes(@sBeginInvokeDestroying); TTask.Create(ASyncResult.DoAsyncDispatch).Start; end; But I confess I do not see the benefits in the above compared to using TTask.Create directly. ITask and IAsyncResult look quite similar. I have not tested but it does not appear to be that hard. var Comp := TComponent.Create(nil) var AsyncResult := Comp.BeginInvoke(procedure begin end, nil); is equivalent to TThread.Queue(nil, procedure begin end); But with a former method you can do a bunch of stuff with AsyncResult (Wait, Cancel, etc,). Also BeginInvoke takes as an argument an Object (Context) that can be useful in some scenarios. And BeginInvoke works with functions and allows you to get a Result back. (like a Future). It appears that the only reason BeginInvoke is a member of TComponent and not even a class function is to offer the ability to customize the dispatch in TComponent descendents: procedure TComponent.TComponentAsyncResult.Schedule; begin FComponent.AsyncSchedule(Self); FComponent := nil; end;

This does appear to be the work of Allen, same as the Delphi Parallel Library. He blogged about it back in 2008.

Further to a previous post of mine, I have done some benchmarking to compare the different alternatives. I am using some old benchmark code from Barry Kelly and added a few more options (word of char in, Char.IsInArray and if then). Here are the 6 ways compared: while not CharInSet(cp^, [#0, #13, #10]) do case statement while not (cp^ in [#0, #13, #10]) do (raises a warning) while not (Word(cp^) in [$0, $A, $D]) do while not (cp^.IsInArray([#0, #13, #10])) do while (cp^<>#0) and (cp^<>#$A) and (cp^<>#$D) do Results with optimization turned on. Win32 1. CharInSet: 0.037 seconds 2. case stmt: 0.039 seconds 3. set test: 0.036 seconds 4. Word set test: 0.037 seconds 5. InArray test: 0.219 seconds 6. if and test: 0.037 seconds Win64 1. CharInSet: 0.106 seconds 2. case stmt: 0.047 seconds 3. set test: 0.042 seconds 4. Word set test: 0.044 seconds 5. InArray test: 0.248 seconds 6. if and test: 0.036 seconds What is worrying is that in 64 bits both CharInSet and IsInArray (the recommended options) are much slower than the alternatives. CharInSet is an inlined version of Option 3, but the code cannot take advantage of the specific contents of the set. Here is the assembly code: CharInSet.dpr.15: while not CharInSet(cp^, [#0, #13, #10]) do 0000000000429DAA 480FB708 movzx rcx,word ptr [rax] 0000000000429DAE 6681F9FF00 cmp cx,$00ff 0000000000429DB3 7711 jnbe P1 + $36 0000000000429DB5 480FB7C9 movzx rcx,cx 0000000000429DB9 480FA30D37000000 bt [rel $00000037],rcx 0000000000429DC1 0F92C1 setb cl 0000000000429DC4 EB02 jmp P1 + $38 0000000000429DC6 33C9 xor ecx,ecx 0000000000429DC8 84C9 test cl,cl 0000000000429DCA 74DA jz P1 + $16 CharInSet.dpr.41: while not (cp^ in [#0, #13, #10]) do 000000000042A05A 480FB708 movzx rcx,word ptr [rax] 000000000042A05E 6683F90F cmp cx,$0f 000000000042A062 7716 jnbe P3 + $3A 000000000042A064 66BA0100 mov dx,$0001 000000000042A068 D3E2 shl edx,cl 000000000042A06A 480FB70D3A000000 movzx rcx,word ptr [rel $0000003a] 000000000042A072 6685CA test dx,cx 000000000042A075 0F95C1 setnz cl 000000000042A078 EB02 jmp P3 + $3C 000000000042A07A 33C9 xor ecx,ecx 000000000042A07C 84C9 test cl,cl 000000000042A07E 74D6 jz P3 + $16 CharInSet.dpr.51: while not (Word(cp^) in [$0, $A, $D]) do 000000000042A1AA 480FB708 movzx rcx,word ptr [rax] 000000000042A1AE 6683F90F cmp cx,$0f 000000000042A1B2 7716 jnbe P4 + $3A 000000000042A1B4 66BA0100 mov dx,$0001 000000000042A1B8 D3E2 shl edx,cl 000000000042A1BA 480FB70D3A000000 movzx rcx,word ptr [rel $0000003a] 000000000042A1C2 6685CA test dx,cx 000000000042A1C5 0F95C1 setnz cl 000000000042A1C8 EB02 jmp P4 + $3C 000000000042A1CA 33C9 xor ecx,ecx 000000000042A1CC 84C9 test cl,cl 000000000042A1CE 74D6 jz P4 + $16 Options 2 and 6 are too verbose and Options 1 and 5 too slow. Option 4 (Word(cp^) in [$0, $A, $D]) produces the same code as option 3 (cp^ in [#0, #13, #10]) without raising an exception and it sounds like a good choice. Any downsides? Incidentally combining any of the above options with an initial test for the most common case e.g. while (Word(cp^) > $D) or not (Word(cp^) in [$0, $A, $D]) do is much faster! Source code attached. CharInSet.dpr

I am not saying that this is the bottleneck. But saving say 1-2/10ths of a second when loading a large file is not insignificant. Especially if it can be easily done.

Isn't this what you are doing with Spring4D?

That begs the question why have the warning and introduce CharInSet only to avoid the warning in the first place. Why din't Embarcadero just eliminate the warning?

Yes indeed. StringLists, TTextReader, SynEdit are full of this kind of shit. When you load a big file scanning millions of characters that has an impact.

The original post was about the best way to replace P^ in [#10, #13] with something concise and efficient in order to avoid the warning assuming the warning is valid. It also showed that the recommended way CharInSet is slow in Win64. So I guess there are two parts to the question: Can I safely ignore the warning? What is a concise and efficient way to achieve the same without a warning? The post also suggests that Ord(P^) in [10, 13] appears to be a good way of avoiding the warning without sacrificing speed or conciseness.

You could suppress just this warning by {$WARN WIDECHAR_REDUCED OFF} while (P < PEndVal) and not (P^ in [#10, #13]) do Inc(P); {$WARN WIDECHAR_REDUCED ON} I prefer the shorter while (P < PEndVal) and not (Ord(P^) in [10, 13]) do Inc(P); The question still is whether the warning makes any sense.