Nasreddine

I have the following style of using Async Await in delphi Async( procedure(aArgs: TnArgs) begin // long time work on worker thread using TThread end). SetReportInThreadException(False). Await( procedure(aArgs: TnArgs) begin // result executed on main thread using TThread.Synchronize(); end ); this works wonderfully for fire and forget pattern, but that means any code after this Async/Await combo will be executed without waiting for the Await part, What I want to do now is refactor my Async/Await code and use function TApplication.ProcessMessage(var Msg: TMsg): Boolean; to block the current execution until I receive a message indicating that the Await part was executed and it is safe to continue the execution of the rest of my code on the main again example of A procedure TAwaiter.AwaitBlocked(aProcArg: TProc<TnArgs>; out AAwaiter: IAwaiter); begin FnThread := TnThread.SetupAsync(FAsyncArg, FProgress, aProcArg, FReportInThreadException); FnThread.Start; AAwaiter := Self; while not TnApplication(Application).nProcessMessage(FTaskID) in [WM_QUIT, WM_MYThreadTaskEndedMsg] do {loop}; end; AwaitBlocked method will create the thread and start it and then that thread will post a message when done. Now to the question, based on your experience, Do you see anything wrong with the design? Keep in mind the following is all taken into consideration: - The user clicks again on the button. - any other special handling that will free the resources needed for the blocked instruction after the await. - Exceptions handling. the end result code Async( procedure(aArgs: TnArgs) begin // long time work on worker thread using TThread end). SetReportInThreadException(False). AwaitBlocked( procedure(aArgs: TnArgs) begin // result executed on main thread using TThread.Synchronize(); end ); // other code to execute that is dependent on what happens in the code executed in the await part, or needs to wait for that part to be done

@Remy Lebeau thank you very much for the advice, I will definitely write a better implementation now then the one I had before. @PeterBelow thank you very much for sharing the part where you process the pending messages, it will help me a lot to make the finale idea come true. Again guys thank you very much for the help.

@FredS @Remy Lebeau Thank you very much guys, I'm refactoring my code now to use MsgWaitForMultipleObjects and see the difference Remy Do you have an example how to pump the message queue in this case? I would like to compare when I'm done.

@Remy Lebeau In that case wouldn't that be the same as my Idea above? block current execution while pumping the message queue, and thank you by the way I did not know you can set it up that way, I always thought it was meant to wait for events.

@FredS What you said is true and I already do it, what I want is to block the current execution until the thread finishes but keep the app responsive. MsgWaitForMultipleObjects will freeze the app waiting for the thread to finish.

@Hans♫ it was permission errors but the new 11.1.2 BigSur update fixed them for the M1 target. this is a confirmed guess I think, we asked them on the latest webinar and they said that they know about the problem but they can not give any time frame about the solution.

I have created an issue in quality portal, I hope you do not mind the picture. https://quality.embarcadero.com/browse/RSP-32375

It is still there just in a new refactored structure but the same logic.

By the way It was really funny to see people trying to know what it is.

the first time I could not see the area where to click to add a vote, but after couple of hours I went back to see the description and I was able to vote. I really hope they fix it fast, I purchased an M1 just to test the project I'm working on and now I can't debug. I'm also facing issues where the app works great on an intel machine but fails on an M1 one. we have to wait at least 8 months for 10.5 to be able to target arm.

I added a comment too, They removed voting????

did you manage to solve it? I have M1 as well and with same error

Cool, I really like the animations, what game engin are you using for the characters?

is it possible to tweek the GExpert tool to search in the background for all function/procedure references and paint the result count on the source editor window like the attached picture? the Grep search feature now works great and it already has the functionality to jump to other files. so my proposition is to make the Grep search for all functions/procedure references that are found on the project path and lib path and the standard paths. then paint the count like visual studio is doing. and when the user clicks on the count the grep window is shown, and in future iteration it can be enhanced to show the implementation where the reference directly. This is just an idea that I had after spending an hour to locate all the references of a function in a large project.

@dummzeuch thank you for the response, and thank you for detailing what is missing, the cod in the picture is c# not c++. it does not always work and sometimes it throws exceptions. RAD Studio is way behind in productivity tools, it always takes me twice the time to do the same job in vs. this can be done and I think there are many examples of how one can do it. so this is not the show stopper I guess. this is the main problem I guess, but I think it can be solved the same way by the code responsible of the feature "go to definition" (initially as proof of concept) so Grep searches for all references (with whole word condition) and then see if the "go to definition" code will lead back to the line in the current file we are doing the search for. do you think an approach like this would work?

This is posted on QR if you want to vote I'm new to the whole pascal thing compared to your customers (I'm only two year old), and I'm using Delphi community edition 10.2.3 for my current development. I just spent more than 6 hours reading posts and topics about the quality of the IDE and how there are many bugs in it (flagging inline variables as error is funny though) and how it is lacking a lot of quality features that are now a days something for granted. I'm being honest here and I would like to say that the first two things I did after those 6 hours was: 1) look for Delphi alternatives (I found few of them that show promise c# and c++ the vs version) 2) come to propose an Idea here. This is mainly coming from love to the Delphi language and its power, but lets be forward here and say that there is no way I'm going to stick around for as long as those guys in stackOverflow did (some of them 20 years!!!!) with an IDE like the current one. So at the end I would like to propose an Idea that could help a bit, Why not fork the VSCode editor and add the basic form designer to it, it is already supporting Delphi through OminiPascal extension and it could even use syntax highlighters and more features that come out of the box that are not in the Delphi IDE for now. It could support every lacking part from the IDE and it is open sourced so you could get some help from other developers on it. I'm only looking for an answer that could heal the hole in my hart for now. Best regards Nasreddine.

@Rudy Velthuis You are right the VS loading time is terribly slow. but I think If Embarcadero continues like this, we will not only have to deal with an IDE that lacks "good gimmicks" but also a very slow one too. If they Continue down this road, they will make it easier to dump the IDE than trying to fix any thing anymore.

@Rudy Velthuis You completely missed the point of my post. I meant the IDE not the WordStar key bindings. in the SO post I linked your comment to the asker was that he should wait for the next major release (Isn't this holding back the wheel). I really like the language but that IDE kills it.

@Rudy Velthuis Elites reinvent the wheel when the wheel stops rolling. Clueless become elites when the wheel don't hold them back from solving problems (currently it is slowing them down)

@David Heffernan I'm in the process of this and it is far better than what the IDE is featuring for now. And by that I mean the following Better source editor (I spend most of my time writing code not moving buttons a round). Better extensions (I had once to hard code a public key and with out a hex extension I would never found the bug I was having) Better refactoring tools. Better themes and long hours relaxing editor (I spend more than 10 hours a day in front of a monitor). I could easily switch to other languages without changing the editor I'm using (talk productivity here), It never spits an AV when you use code completion (Never could reproduce that bug). And the last one. every one is using this thing and rare are who complained about it (I'm speaking quality). @Rudy Velthuis I'm 26 Hydrocarbons and chemistry graduate but I'm not a chemist, this is what you can do best in my country Algeria, I was using c# and c++ for most what I do. The first time I used Delphi 7 I was hooked by the simplicity and power. I created a whole set of components, a crypto library, custom threading component and a very customizable VCL ListView with only asking 20 questions on Stack Overflow (good luck understanding those in c#). I also want to say that Delphi has opened my eyes about how to code and be good at debugging things, so I really love it. As for extending the IDE, well you just said it, what I have in VSCode is not an extension to the editor it is already built into it. @Stefan Glienke I think when coding you use the editor most of the time, every thing else is a feature that saves more time, but if the editor is slowing you down then the rest is just a signal of hope you see time to time. and what I'm suggesting is not an extension, it is a rework to the Delphi IDE on something that proved quality and productivity over time. @Darian Miller I did and thank you. @dummzeuch My concern exactly. I would like to say thank you for all of you at Stack Overflow and here for helping others get to the Delphi world, It is an honor reading what you post.