Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Windows context menu handler
See original GitHub issueCurrently I’m working on a context menu handler for Windows Explorer. I wrote it in Delphi and was able to port it to Lazarus/FPC. It runs fine.
Installation of the handler is done via regsvr32 "<path-to-DLL-file>" and requires admin rights. The handler needs the path to CudaText in order to be able to run it. Currently I place the DLL file in the same directory like CudaText, thus I’m able to retrieve Cud’s path by retrieving the DLL path and adding CudaText.exe.
What is your opinion about storage path of the DLL? What do you think is the best way of integrating the handler’s installation into CudaText?
Issue Analytics
- State:
- Created 4 years ago
- Comments:25 (25 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@vhanla
With a context menu entry based on simple registry keys it is not possible to open more than 15 files. If you select more than 15 files in an Explorer window, the context menu entry disappears.
Moreover, with a context menu entry based on simple registry keys Explorer starts an instance of CudaText for every selected file. My context menu extension starts only one instance of CudaText for every packet of 125 files. Thus, startup speed increases significantly.
Ok, I am closing this, DLLs will be in next Cud release