I'm trying to use Kivy as a GUI for my python app, which needs to read a file from the filesystem.
However, in some cases the kivy filechooser read wrong path or nothing causing an IndexError while I'm trying to set the read path for a text of a textfield.
I use the default example for reading files learned from http://kivy.org/docs/api-kivy.uix.filechooser.html
The relevant part of my app is in this function, where an exception handling is added as a not a good approach to handle this :)
def load(self, path, filename):
'''
this will load the file and dismiss the dialog
'''
print "Loading file..."
print "filename:",filename
print "path:",path
try:
self.selected_file = filename[0]
self.file_text_input.text = self.selected_file
self.dismiss_popup()
except IndexError as ie:
print "Something made a boo-boo...try again"+str(ie)
self.dismiss_popup()
self.show_popup("ERROR","Somehow I couldn't load the file:\nCheck the permissions or move it to other place")
self.show_popup() is just a helper function, which shows a popup with the set function params.
The basic error is that filename[0] will throw an IndexError since it does not read the correct path.
I'm using Linux with python2.7, and somethimes when I select a file in my home folder, the filename variable stores nothing, while path variable stores misteriously a random folder, for instance, /media, /opt, etc.
Did anyone meet this issue?
I found out why it was handled uncorrectly.
All the failures are caused by Kivy's
FileChooserListView
, which enables to click on folders and files via a list, but it also makes it possible to have a littel '>' sign at the beginning of every list element, which are directories.
I realized that when I used these '>' signs, then I get wrong path, but if I always clicks on the directories' list elements then everything works fine.
However, that little '>' cannot be disabled (for now), so the best and fastest alternate solution is using
FileChooserIconView
instead!
Now everything is good :)
Related
I'm writing a Lua program that must prompt the user for a directory as one of a number of parameters for an operation (that involves copying a file to a target directory with a new name). Environment is Windows; I'm using Lua 5.1.
The relevant code currently looks like
require("iuplua")
local mediaFolder = "C:\some folder\some subfolder\"
local pPrompt = --this is a subset of the parameters
"File name: %s\n"..
"Destination: %f[DIR||"..mediaFolder.."]\n"
ret, strTargetFile, strTargetPath =
iup.GetParam("Add Media from file ", param_action, pPrompt, "Initial file name", mediaFolder)
The resultant GUI looks like:
but when the selector button (...) is pressed, the initial directory shown is not C:\some folder\some subfolder\ but whatever directory was last navigated to in the interface, and it isn't possible to select a directory, only a file.
I'm guessing I have a fundamental misunderstanding of how this should work? Is what I want to do possible with iup? Ideally, I'd also like to restrict the user to only selecting the initial directory or one of its sub-directories rather than navigating anywhere outside that directory structure, and to allow the user to create a new sub-folder.
This looks like a bug. I'll check it.
Don't know if Stack Overflow is a place for bug reports, but I monitor iup posts here.
Best
Trying to replicate this simple Lua example (using the improved code in the second post), I encountered the following strange issue:
I copied the code verbatim, but happened to call the first file "table.lua" (instead of "funcs.lua").
The second file was called "main.lua" as in the example.
In my case, whatever I tried, I invariably got the popular error message "attempt to call field 'myfunc' (a nil value)" (as if the require statement had been ignored; but path etc. were all in order).
After two hours of trying and hunting for info, I more or less on a hunch renamed the first file from "table.lua" to "tabble.lua", and then everything promptly worked as expected. Renaming to e.g. "tables.lua" will also work.
Being very new to Lua, I'd still like to understand what exactly went wrong. Initially I thought the reason might be that "table" is a reserved Lua word, but all references I checked do not list it as such.
So what is going on here?
I am using LuaForWindows v5.1.4-46 with the included SciTE editor/IDE (v.1.75).
Thanks for all hints.
The standard libraries math, io, string, …, and table are pre-defined (and pre-loaded) in the Lua interpreter. Because require caches modules by name, saying require "table" will return the standard table library instead of loading your own table module from a file.
A good way to solve the problem is to create a folder and put your library files in there. If the folder is called mylib, then require "mylib.table" will work and load the file.
Alternatively, if you just need to load the file once and do not need the features of require (searching the file in a number of directories, caching loaded libraries), you can use loadfile: Change require "table" to loadfile "./table.lua" () (where ./table.lua should be the full (relative is fine) path to the file.)
usually when I have a question about something remotely software related I find that someone else has already asked the very same thing, and gotten good answers that works for me too.
This time, though, I've failed to find an answer to my predicament.
Here we go:
I'm currently trying to move up my Lua-programming a notch or three and want to use modules. So, I've got a structure like this:
main.lua
foo/bar.lua
Now, in main.lua I do
require("foo.bar")
which fails,
main.lua:1 module 'foo.bar' not found:
no field package.preload['foo.bar']
no file 'foo.bar.lua'
no file 'foo.bar.lua'
no file 'foo.lua'
Ok, something might be wrong with my package.path so I use package.searchpath("foo.bar", package.path) to see what I', doing wrong.
The problem is that package.searchpath resolves foo.bar to foo/bar.lua which is exactly right.
As I've understood it, package.searchpath tries to find the module in the same way as require, but there seems to be som glitch in my case.
What strikes me as odd is the repetition of the no file 'foo.bar.lua' in the error output
Have I misunderstood the use of require?
I'm using LuaJIT-2.0.0 to run my chunks
Update:
I'm using LuaJIT-2.0.0 to run my chunks <- This was the reason for my problem, stock Lua-5.2.2 behaves as expected
package.path = debug.getinfo(1,"S").source:match[[^#?(.*[\/])[^\/]-$]] .."?.lua;".. package.path
require("foo.bar")
This line causes require to look in the same directory as the
current file when asked to load other files. If you want it to instead
search a directory relative to the current directory, insert the
relative path between " and ?.lua
Here is part of require description:
[...] Otherwise require searches for a Lua loader using the path stored in
package.path. If that also fails, it searches for a C loader using the
path stored in package.cpath. If that also fails, it tries an
all-in-one loader (see package.loaders).
Default path for package.path is always the .exe that executes specified script.
So I have a Rails application that upon user submission should generate some kind of a .tex file based on the user input, compile it into a pdf, and deliver the pdf. Through process of elimination, I am pretty positive that everything is working except for one line; the one where pdflatex is called.
Here's the vital snippet of code:
(If it matters, its located in the Questions controller under the generate action, which is called after the form sends the relevant information. Though this may not be the best way, I'm pretty certain its not the cause of the error)
texHeader = 'app\assets\tex\QuestionsFront.txt'
texOut = 'app\assets\tex\Questions.tex'
#copy latex header to new file
FileUtils.cp(texHeader, texOut)
File.open(texOut, 'a+') do |fout|
fout.write("\n")
# a loop writes some more code to fout (its quite lengthy)
fout.write("\\end{enumerate}\n")
fout.write("\\end{document}")
#The problem line:
puts `pdflatex app/assets/tex/Questions.tex --output-directory=app/assets/tex`
end
filename = 'Questions.pdf'
filelocation = "app\\assets\\tex\\" + filename
File.open(filelocation, 'r') do |file|
send_file file, :filename => filename, :type => "application/pdf", :disposition => "attachment"
end
end
Here's my reasoning: It generates the .tex file correctly, and given a pre-created Questions.pdf file it sends it just fine. When the command in the puts is copied to the terminal, it runs without a hitch (the file begins with \nonstopmode so no worries about small errors). But for some reason, when I run the above script, not even a log file is created with an error.
What am I overlooking? Any ideas? Any way of seeing what output the puts line is creating?
Thanks so much in advance!
Figured out my own problem. The error is pretty interesting. You'll see I'm calling
puts `pdflatex app/assets/tex/Questions.tex --output-directory=app/assets/tex`
within the block
File.open(texOut, 'a+') do |fout|
where just a few lines prior
texOut = 'app\assets\tex\Questions.tex'
Basically, I'm trying to get latex to compile a document while the file is still open. So long as I'm in the File.open block, the file is open, and its automatically closed upon the end of the block.
Cutting and pasting the line of code down below the end of the block made it work just like I wanted. However, for the sake of clarity and the rare case where someone else has this problem, its actually better to open a separate system shell, navigate to the directory where the latex document is and do the compiling there. So, my updated code looks like:
fout.write("\\end{document}")
end
system 'runlatex.bat'
where that batch file is as follows:
cd app/assets/tex
pdflatex Questions.tex
That way any additional files in the tex directory are found, the log file is created there, etc.
Reason why I never got a log file? The pdflatex never executed - the OS stopped it with a permissions error before it ever ran.
Hope this helps!
Backticks (and %x{}) provide the same parsing context as a double quoted string. That means that the usual backslashed escape sequences are interpreted inside backticks; in particular, \t is a tab so this:
puts `pdflatex app\assets\tex\Questions.tex --output-directory=app\assets\tex`
will end up with two tabs in and that breaks everything. You can start escaping your backslashes (I think you'll need two or three backslashes to get one down to the shell) or switch to normal slashes (which Windows usually accepts in paths):
puts `pdflatex app/assets/tex/Questions.tex --output-directory=app/assets/tex`
Alternatively, you could switch to open3 to avoid the escaping and quoting issues and also get better error handling capabilities.
My program accepts input file names either as command line parameters or in a drag and drop operation or in Explorer by clicking on filenames with an extension that is associated with my program.
The command line and drag and drop work fine, but it is clicking on the filenames in Explorer that causes problems when the filepaths of the files clicked on have spaces in them, e.g.:
c:\temp\file one.txt
c:\my directory\filetwo.txt
c:\my directory\file three.txt
then, the ParamStr function gives me back:
ParamStr(1): c:\temp\file
ParamStr(2): one.txt
ParamStr(3): c:\my
ParamStr(4): directory\filetwo.txt
ParamStr(5): c:\my
ParamStr(6): directory\file
ParamStr(7): three.txt
How can I best reconstitute these back into the three filenames that I need?
It might be your shell file association that does not include the pair of "".
Like these ones for opening:
"C:\Program Files\WinRAR\WinRAR.exe" "%1"
or with DDE message:
[open("%1")]
Command-line parameters with spaces in them, such as filenames, should be quoted. This makes the param parser realize that it's supposed to keep them together. If the user's not quoting the filename, it's operator error.
If a drag-and-drop system is doing this, on the other hand, then you've got a bug in your drag-and-drop library and you need to talk to whoever created it. I'm a bit confused, though, as to why drag-and-drop operations are messing with ParamStr. That should only be set by the params passed to your program at the moment it's invoked, not once it's up and running. Maybe I'm missing something?
i use the CmdLineHelper unit, from here.