Anders Melander

Why do you ask?

I'm way past caring about disk space. For example we use DevExpress in almost all desktop projects and in addition to the regular install, which we need for design time support, help, examples, etc., each project has a complete copy of the DevExpress source files to make sure the projects are autonomous, under full revision control and are always built with the correct version. That's 120 Mb in 3000 files - per project, per branch, etc. Yes, a global package cache could reduce that to a single copy, but it would be pointless. The problem we have isn't disk space. It's creating a reliable, robust and foolproof development environment. Yes, but I would prefer to have complete control over where that exact location is. I'm not saying that it's unreasonable to require at least some adaptation of a project for use with DPM but for me at least it will be a showstopper if use of DPM becomes a requirement once the project has been adapted and having the package cache in the project search path, and the search path controlled by DPM, is such a requirement as far as I can tell. I guess right now I'm focusing on how DPM could fit in with my existing projects where I already have all dependencies sorted out and folders and search paths assigned. I understand the use cases of dependency resolution, the package cache and updating the search path, but I'm not sure the convenience they offer is worth sacrificing the autonomy I already have in place for the projects I manage. Now if only DPM had been a standard part of Delphi then it would have been an entirely different matter.

My guess is that you have two monitors; Primary with 125% zoom and secondary with 100% zoom. This setup appears to freak the IDE out.

Yes.

I would have preferred it to be zero or one copies: The package cache would just contain the meta data and optionally a single copy (per version) of the source files. On update the package manager would copy the specified source files to a local folder specified in the project options. This way there would be no dependency between the project and DPM and the the project would be completely autonomous. As far as I can tell, the system you have now creates a dependency between the project and DPM because the project search path has to include DPM specific folders - local or not. There's also a duplicate binding between the project and the package version because the version is specified in both the dpm.config file and in the project search path. It should be sufficient to specify the version in the config file.

That's not my understanding. As I read it the package cache can be either global or per project. Regardless I can't see the problem of each project having their own copy of dependent libraries - unless it's the JCL in which case even a single copy is a problem 🙂 Disk space is cheap. Time is not.

No. But while you're peeking at the message queue you might as well do something useful with it: procedure BusyBusyBusy; begin // Allow threads to synchronize CheckSynchronize; Msg.message := 0; try // Process cursor update messages for this window so cursor stays responsive while (PeekMessage(Msg, Handle, WM_SETCURSOR, WM_SETCURSOR, PM_REMOVE)) do begin if (Msg.message = WM_QUIT) then exit; DispatchMessage(Msg); end; // Process paint messages for all windows so UI can repaint itself while PeekMessage(Msg, 0, WM_PAINT, WM_PAINT, PM_REMOVE) or PeekMessage(Msg, 0, WM_ERASEBKGND, WM_ERASEBKGND, PM_REMOVE) or PeekMessage(Msg, 0, DXM_SKINS_POSTREDRAW, DXM_SKINS_POSTREDRAW, PM_REMOVE) or PeekMessage(Msg, 0, WM_PRINT, WM_PRINT, PM_REMOVE) or PeekMessage(Msg, 0, WM_PRINTCLIENT, WM_PRINTCLIENT, PM_REMOVE) do begin if (Msg.message = WM_QUIT) then exit; DispatchMessage(Msg); end; PeekMessage(Msg, 0, WM_NULL, WM_NULL, PM_NOREMOVE); // Avoid window ghosting due to unresponsiveness on Vista+ finally if (Msg.message = WM_QUIT) then begin PostQuitMessage(Msg.wParam); Application.Terminate; end; end; end; The above was snipped from existing code so might need to be tweaked slightly.

OK. Good luck then.

You don't need to open the form to compile the project. But if you need to see what the example source looks like, open the unit, ignore the error messages about unknown components, look through the source, close the unit without saving the changes.

No it doesn't. Looking at the source also doesn't require installing them I'm a contributor to Graphics32 and I don't have the component installed.

You don't have to install anything but you could at least read the documentation and examine the examples...

Completely OT but in Denmark every citizen has a personal certificate issued by the state for verification of online identity etc. This was introduced 20 years or so ago. In theory this certificate can be used for code signing (and I used to do so) but about ten years back the state outsourced the whole operation, implementation and infrastructure, to a private company (Nets DanID) which then introduced a solution called NemID (rimes with GlemID and SlemID = ForgetID and BadID). NemID is still based on certificates but it's so idiotically implemented that both the public and private keys are stored on the Nets servers. In other words: I don't have access to my own private keys and I have no control over who has access to them. Sorry. I get really pissed off every time someone mentions certificates 🙂

New version released: v1.0.7271.54299 http://melander.dk/download/amTranslationManagerInstall-1.0.7271.54299.exe Changes since v1.0.7254.4932 New features: GNU GetText PO file import. Improvements: Copy to clipboard not uses tab delimited CSV for better integration with Excel. Normalization rules can now be configured. New validation rules: pipe | and surround ()[]{}<> mismatch. Validation warnings can now be dismissed and resolved. New equalization rules: Leading space and Trailing space. Duplicates in Translation Memory lookup results are now ranked by the similarity of the translation source to the value being looked up. Other: Installation of the command line tool is now optional. Primarily because it is currently being flagged as a false positive by several virus checkers. Removed dependency on midas.dll A slew of performance and usability improvements and bug fixes. Thank you to all those that have sent me suggestions, feedback and bug reports.

https://www.sourcetrail.com/blog/open_source/ Also Wow. Bold move and I hope it turns out good for them. I can't help but think of Borland who went for the exact opposite solution (remember Inprise?) and almost killed Delphi in the process. And we're still paying the price for that fiasco - literally.

You need to examine the call stack of all the threads. When you break the call stack is just shown for the currently active thread which is rarely the one you're interested in. P.S. I can see from your video that you have DropBox installed...

If you can reproduce the problem then simply run the application in the debugger, break when the problem occurs and examine the callstacks. ...however; My usual advice when people experience this kind of progressive or periodic slowdown/lockup is to uninstall the various cloud storage services they have running (ITunes, Google Drive, OneDrive, etc.). Solves the problem in 9 out of 10 cases.

I've been using it since the first version (which AFAIR was before XE) with no major problems. Maybe because my style is pretty standard (aka the One True Style ). One thing I've never gotten to work though is formatting a block of text: It always formats the whole file. No biggie. It's usually the first step I do when I'm brought in to fix other peoples code.

To paraphrase David Heffernan: That is utter nonsense and it doesn't appear that your Professor Lee has much practical knowledge about how to work safely with threads. Or maybe he's just using hyperbole to get a point across. Under any circumstances, Quoting academia? To disprove the opinions of a professional, highly skilled and experienced developer? Really? How about some arguments based on your own knowledge and experience... Many of us use threads on a daily basis and do so without wreaking havoc in the universe. If you understand the pitfalls of multi threading, know how to protect your resources, synchronize execution, understand race conditions, etc. etc., then threads are just another tool in the box. If you don't understand threading then yes, it will hurt you in a gazzilion ways you literally (and I use that word in the European sense) didn't think possible.

Actually it might. One of my grieves with the Refactor menu item is that if you accidentally move the mouse over the menu item (e.g. on the way to the View or Project menu item) then there's a noticeable delay (very noticeable on low end systems) as the IDE loads the refactor stuff (among it the J# run time I suspect) in order to populate the sub menu. Agree, but I don't think I'll have more to contribute on the subject.

Yes but that also removes the stuff I use and which actually works (mostly): "Find References" and "Rename".

Oh... This is the GExperts sub forum... I didn't notice that so I actually thought you meant the IDE main menu (which is what I was talking about). Well then, pls ignore what I said.

They can start by getting rid of the Refactor menu - and that might also improve the stability of the IDE.

Then the thread will be killed when the application terminates. The point is that it's better to forget about the thread, report a timeout and continue as if the thread had been forcefully terminated. Of course if the thread has allocated or is blocking resources then that solution might not work.

I'm assuming the above is just an example to explain what you need - since if you can kill the thread from within the thread, then the thread isn't frozen and you could just exit it the normal way. I completely agree. Just don't do it. What you could do is signal the thread (use an event, a boolean, whatever) that it has become thread-non-grata and then just forget about it. If the blocking call ever returns then your thread can check the signal and terminate. E.g. something like this in your TThread.Execute procedure TMyThread.Execute; begin while (not Terminated) do begin CallStuffThatMightBlockForever; if (FNotInterestedAnymore) then break; end; end;

Additionally, RegSaveKey doesn't save in .reg format but in registry hive format. There is no API for saving in .reg format.