I'm working on an application in Lua and I wish to have the user be able to open a directory in the OS's GUI so they can edit it's contents. I don't care to track any changes made; basically I just want to open a new process. For Windows, I just use os.execute to open a Explorer window; however, I am uncertain how to do something similar for other operating systems. What are the Lua-callable equivalents for Explorer in other systems? I don't mind having to use an external library.
In Mac OS X you can do os.execute("open ~") to open a Finder window with your home directory.
Back when I used Linux, I wrote a version of open that used nautilus ~ to open the home directory in the file browser in Gnome. I'm not sure the file browser is still called nautilus or what is the equivalent in other Linux distributions.
Related
I am running :
fedora32
mate desktop environment
wayland
marco window manager
xterm
emacs -nw (text mode)
emacs dired+ mode
emacs "openwith" mode
When I start up "emacs -nw" in the xterm it uses "dired+" mode to give a directory listing.
The emacs "openwith" package has associations for ".pdf" and other file extensions.
What "openwith" does is when I put the cursor on a line in the directory listing
and press "f" or "v" to find or view the file, openwith launches an external program
(e.g. "okular") to view the pdf file.
The problem is that when the external program (e.g. "okular") exits,
the window manager focus does not return to the xterm running emacs.
This does not only happen with this pair of programs (xterm and okular).
In general, when you exit a program
(any program, not just one launched from emacs and xterm as described above),
you can not rely on the window focus returning to where you last were.
It is annoying.
I am pretty sure there used to be some kind of stack holding the window focus
so it would return to the previously focused windows in turn.
This problem is not present in mate with the compiz window manager, but that
has other problems.
I'm using Delphi 10.1 on Windows 10
When I run the OpenPictureDialog.Execute command
on some app it's open File Explorer with a preview area and on others without.
I have exactly the same properties on both cases.
What can cause the difference?
Thanks Sorin
function GetOpenFileName; external commdlg32 name 'GetOpenFileNameA';
function GetOpenFileNameA; external commdlg32 name 'GetOpenFileNameA';
function GetOpenFileNameW; external commdlg32 name 'GetOpenFileNameW';
In older versions on Delphi it used a Windows API function in comdlg32.dll to open a file. I would think it is the same in newer versions. What you see in terms of preview etc. is down to Windows settings.
The dialog shows to the user will be consistent with other file open dialogs they see on their system.
How do you add windows explorer shell context menu to 64-bit OS like this example here Simple Context Menu for jpg files?
Why doesn't adding the registry key HKEY_CLASSES_ROOT\jpegfile\shell\Simple Context Menu\command\path to exe work like it does in 32-bit? People have told me it's because you can't access 32-bit exe but I'm pointing it to a 64-bit exe? Can you not do this in 64-bit OS? Why is it so simple in 32-bit??
Found this user here on stackoverflow with same problem but no solution.
Can you not simply add it like you do in 32-bit OS?
Convert might be the wrong word, but to save a user having to install something I wondered if a small EXE can be embedded in a web-page (IE only) using ActiveX so it is run when a button is pressed. Obviously a big security hole but is it feasible?
Urgh, just thinking about it makes me die a little inside.
But yes, package up the exe and the activex in a cab file and use the activex to launch the exe.
Info on packaging up ActiveX cab files is here: http://msdn.microsoft.com/en-us/library/aa751974(v=vs.85).aspx
A bit more information on Inf files (specifically the DestDir bit): http://msdn.microsoft.com/en-us/library/aa741215(v=vs.85).aspx
This would allow you to put the exe in a known location (Windows or System) so that you could execute it from the activex control providing permissions were set correctly
It's easiest when developing in the IDE to work with a Application target folder in the default location into which it will be installed e.g:
"c:\Program Files\MyAppFolder"
As a result, I have "c:\Program Files\MyAppFolder" coded into the Delphi project's 'Output directory' and I can prepare for development by running my installer (Innosetup) which populates that folder with supporting data files etc.
Now I'm moving between Windows7 64 and Windows 7 32 and my installer wants to put it's (32-bit) app into "c:\Program Files (x86)", so I need to point my IDE output at:
"c:\Program Files (86)\MyAppFolder"
This would be a change required in each project. Is there a predefined variable that I can use or some other method that would allow me to move between platforms with a 32-bit app?
It's easiest when developing in the IDE to work with a Application target folder in the default location into which it will be installed e.g
Your application is supposed to work wherever the user installs it, and you obviously know that since you call the location "the default location". Since the app should work wherever you install it, it shouldn't matter where you're developing it.
Your Program Files choice is bad for a number of reasons:
If you make the mistake of hard-coding a path in your application, you'll only learn about it when a client installs the application somewhere else.
Doing your development in the Program Files folder requires you to work with UAC disabled: your client's are going to have UAC enabled, so you're not actually working in an environment that looks like the environment where the app is going to be used.
You can't test application's installer: since you already have files in the "default location".
Program Files goes through two folder redirectors: The 64 bit virtualization that makes 32 bit application read from Program Files x86 when they say Program Files and the UAC virtualization that redirects write access to Program Files folders to folders in one's UserData directory.
It's my honest opinion that it's better to develop into an other directory, outside the Program Files minefield. For my own development I'm taking this to the next level: The same applications is developed in different folders on different computers. Example: I've got my app checked out in C:\Appname, my colleague has it in D:\SomeFolder\AppName
You can use environment variables when specifying paths in Delphi.
Set output directory to $(ProgramFiles)\MyAppFolder.
$(ProgramFiles) in Win64 points to Program Files x(86) for 32-bit applications. Delphi is 32-bit so that will work for you.
This wouldn't work for me because I have UAC enabled. I'd just stick it somewhere outside the program files folders.