c0d3r
-
Content Count
129 -
Joined
-
Last visited
-
Days Won
1
Posts posted by c0d3r
-
-
32 minutes ago, programmerdelphi2k said:my bet is: verify the setup BIOS
What should I look into?
-
22 minutes ago, programmerdelphi2k said:if many works, and 1 dont, my bet is: verify the setup BIOS, verify if same Windows edition or setup, etc...
Works for some, won't work for others (not only 1), and they are on Windows 10
-
16 minutes ago, Angus Robertson said:Check the WM_POWER message as well.
Angus
The WM_POWER message is obsolete. It is provided only for compatibility with 16-bit Windows-based applications. Applications should use the WM_POWERBROADCAST message.
-
HI, All
I'm getting a strange issue, the following codes were trying logout users when Windows is going to sleep mode. For some reason, it works for some laptops, but it doesn't work for others:
procedure WMPowerBroadCast(var Msg: TMessage); message WM_POWERBROADCAST;
procedure TMainForm.WMPowerBroadCast(var Msg: TMessage);
begin
if (Msg.wParam = PBT_APMSUSPEND) or (Msg.wParam = PBT_APMSTANDBY) then
begin
try
Signout;
except
end;
Msg.Result := 1;
end;
end;Got the report from my client, the signout routine didn't get called when some laptops went to sleep (leave them opened and auto entered Sleep mode or Hitting Power button to force sleeping), but other laptops/PCs were working just fine.
-
Thanks, I meant thread-personal instances, no shared streams.
-
HI, All
Using Delphi 10.4.2, just wondering if TCompressionStream and TDecompressionStream in System.Zlib unit thread safe or not? Thanks.
-
@Remy LebeauAlthough we still can't figure it out after weeks (we don't deal with any TCP/IP socket codes), we found a workaround: kbmMW's Server component has a property called 'DisconnectAfterResponse'. By setting it to True, Most of our clinic customers don't have any TCP/IP socket close freezing issues, however few were still having the problem, they were the large and busiest clinics. We are planning to use Indy Github version to see if it helps, I'm just wondering whats difference between GitHub version and the one comes with Sydeny?
-
-
-
Anyone has the same problem? Delphi 10.4.2, Press Ctrl+Shift+F on any word, Find in Files screen pops up, After a bit frozne, crashed the IDE. The workaround I can only found is that: It works fine after disabling Refactor menu.
-
Feel better!
- 1
-
On 2/24/2021 at 10:38 AM, dummzeuch said:I read somewhere (when I was searching for 'Yield'), that Yield doesn't exist on Arm processors and there simply translates to NOP. Not sure whether I understood that correctly because at the time I wasn't really interested in Arm.
-
-
I can confirm all as well, went back to Classic, don't see why I should use LSP.
- 1
-
No issue on VMWare 16.1.0, Win10, 4K, 100%, Delphi 10.4.2
-
9 hours ago, Trevor S said:The 64bit path issue is listed in the "Known Issues" section of the installation notes.
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Installation_Notes#Known_Installation_Issues
Sorry, too late for you now...
It said the problem would occurs when using offline installer, but I was using web installer, still my 64bit LIBRARY (Windows) paths were wiped out.
-
I saw the code in Delphi 10.4.2, but I don't see any forms flickering in Window 10.
- 1
-
1 hour ago, Steve Maughan said:I made the mistake of updating as soon as it was released. After installing (all default option) I found it had scrubbed my Win64 component path. The Win32 path is in tact but it'll be a right old pain to manually copy between the two. Also had to re-install OnGuard and Konopka components via GetIt (a modest pain).
Be warned,
Steve
Yeah, all my win64 component paths were wiped out. Luckily, I had backup the registry before upgrade, so re-import the registry solves.
- 1
-
15 hours ago, chmichael said:Well i made him notice you! Post the report on his forums and if it's an Indy bug i'm sure that @Remy Lebeau will help!
I got Kim's emails 3 days ago. Thanks.
- 1
-
1 hour ago, Remy Lebeau said:That is why I keep asking you to SHOW YOUR CODE (or at least a small demo that reproduces the same issue). We can't tell you what is wrong if we can't see what you are actually doing.
No. It is your responsibility to not write code that blocks the socket threads from terminating properly.
@Remy Lebeau I would like to give the codes, but I'm not allow to, they are kbmMW codes, all socket threads related things are done by kbmMW components internally. What we did was just wrote codes in one of its OnRequest event handler to deal with client request by the given request name, and set the return Result. For each request, We made 100% sure to have try--finally--end blocks to have objects created get freed properly, each LockList to has a matched UnlockList to access thread string lists, ..., etc. Anyway, Thanks for your time to anwser all my questions, really appreciated!
The codes in ProcessRequest event:
@ServiceMethod := MethodAddress(AClientRequestName); if Assigned(ServiceMethod) then begin Result := ServiceMethod(Self, ClientIdent, Args); Handled := True; end;
This one of the request codes we wrote (in published section):
function TMyService.GetSequenceValue(const ClientIdent: TkbmMWClientIdentity; const Args: array of Variant): Variant; var ds: TkbmMWDataset; SeqName, Step: string; SeqList: TStringList; i: Integer; begin Result := -1; if not PrepareQuery(SEQUENCE_GETVALUE, ds) then Exit; try SeqName := VarToStr(Args[0]); Step := VarToStr(Args[1]); SeqList := FSequences.LockList; try i := SeqList.IndexOfName(SeqName); if i < 0 then Exit; SeqName := SeqList.ValueFromIndex[i]; finally FSequences.UnlockList; end; ds.Query.Text := Format(ds.Query.Text, [SeqName, Step]); ds.Open; if not ds.Eof then Result := ds.FieldByName('ID').AsInteger; finally ds.Free; end; end;
-
3 hours ago, Remy Lebeau said:Well, then that goes back to my earlier question - what do those methods actually look like? Because there is likely a deadlock happening inside one of them, preventing one or more socket threads from terminating correctly, thus causing the TIdTCPServer.Active property setter to hang waiting for it.
@Remy Lebeau Thanks, I totally agree it. just not sure how to find. Any workarounds we can do? Is there any properties/methods in TidTCPServer that can let all these socket threads being terminated gracefully before calling FSocket.Active := False;
-
17 minutes ago, Remy Lebeau said:You can't use TIdTCPServer without at least an OnExecute event handler, otherwise setting the Active property to true will raise an EIdTCPNoOnExecute exception. Are you suggesting that your OnExecute handler is blank, doing nothing at all?
I'm not familiar with kbmMW, why are you using TIdTCPServer at all if it does nothing? I don't understand the rational here.
As I said earlier, setting TIdTCPServer.Active to False will handle the disconnect of active client sockets, closing the listening sockets, and waiting for their threads to fully terminate.
Sorry, I didn't make it clear. its the kbmMWTCPIPIndyServerTransport that use its FSocket: TidTCPServer, to handle everything using some private/protected/public methods, including Execute event. e.g.
TransportServer.Listen -> FSocket.Active := True;
TransportServer.Close -> FSocket.Active := False;
-
5 hours ago, Kas Ob. said:My thought on this, and i never used the library, so it is a guess work
Getting FIN_WAIT_1 should have triggered a flag somewhere, so it is one of the following
1) An exception was raised and you silently ignoring it, or the kbmMW did ignored it silently, and that is wrong, this is unlikely by the library.
2) kbmMW is capturing it and passing it to an event to be handled or observed, and you missed assigning such event (callback)
3) kbmMW is buggy, it is unlikely, i think such library is already mature enough after all these years to miss such basic functionality.
Also here from this
I think there is something missing, here because calling TransportServer.Close ; should not be that simple to handle exactly these cases where there is an active connection, so it either you should be calling something before Close like Dissconnect, abort, StopListen... or Close itself can have a parameter like Close(True), that is the right and normal design for any sockets handling library, unless there is some properties can be should be control this process of closing/disconnecting.
in any case, i think you should refer to the documentation, browse the demos and look for the right way to close/terminate.
No Disconnect/StopListen method, only Listen and Close, and the codes were there for 10+ years since 2007, people who use our old app (built with Delphi 2007, Indy 9) are still working great. Its those people who upgraded to our new app (built with Delphi 10.4.1, Indy 10) are having the issue.
-
8 hours ago, chmichael said:cod3r are you sure that it isn't a kbmMW bug that you should report to Kim ?
As usual I sent email to Kim last week, no response. Wish me luck if I get response. Try registrating to its forum to ask questions, nope, my work email was used and can't register, try 'Forgot/Lost Password' link, Oops, your email doesn't exist. I sent email to Kim about registration issue on Sunday, lets see when I would get the response, so far no any response.
EDIT: Oh, Oh, the only email I can always get from him was the email that asking me to pay the annual subscription fee on due date.
Getting Windows Sleep message, works for some computers but doesn't work for others.
in Windows API
Posted · Edited by c0d3r
Something must be changed, was told it was working just fine on the same computer, and then stop working. They are using Windows 10.