is there a way to get a file list recursively based on one file collection that points to a directory in fileadmin?
Currently I only got it to work with files directly in that directory, not also with files in sub-directories of that directory.
So instead of setting lots of file collections for each (sub directory)
I'd like to set only the "top"level directory (here "Kurs77") and have the files, even from sub directories, displayed.
Reason is, editors may add an unknown amount of (sub)sdirectories, and I'd like to have the files automagically displayed in the file list in the front end -- without the need to create an increasing amount of file collections.
cheers,
Tom
it seems that this is a missing feature. Check out https://forge.typo3.org/issues/61238. It seems that the underlaying API is able to do that.
So one solution would be to use TypoScript to make that work.
To give the correct answer now: The recursive option is of course available but it is part of the sys_file_collection record.
In TYPO3 9 this is working out of the box. pity is not showing folder as title, but recursive works:
Related
I have mutiple folders I want to include in doxywizard. Any Idea how can I do that? Currently If I select folder with multiple subfolder in it and when I run doxygen, It is not showing me any output.
When having specified just folders in the INPUT tag the files here are handled but not the files in subdirectories. For the later ones one needs the RECURSIVE tag (from the documentation):
RECURSIVE
The RECURSIVE tag can be used to specify whether or not subdirectories should be searched for input files as well.
The default value is: NO.
I created a RoboHelp html help project that merges three projects into a master project. Indexes and search terms work fine in the Master.chm. However, this Master.chm gets merged into another "Super-Master" application that my application is a plug-in for. After that merge, the sub help .chms items do NOT appear in index and search does not find them. Is there a limited number of "levels" merged help will allow index/search to work? Or is it more likely there is some other problem (ie. Super project doesn't use Binary index) or something?
Mostly it's the binary index. Please check following list of general tips from Rob Chandler's website:
All CHM files should be installed to the same folder.
You can install any number of Slave CHMs but the Master CHM must always be installed if you want the slaves to reference the master
Table Of Contents.
Each project must enable the "Binary Index" in order for index merge to work.
A binary index will not be created if you select 1.0 as the version in the Compatibility box > Compiler tab > Project Options
dialog or if the Create a binary index check box is cleared.
Rick Stone reminded that the Master index must contain at least one index term in order for the merge to work.
Similarly "Binary TOC" must be disabled otherwise merge will not work.
Include HHC works recursively, so you can have groups of optional modules. I.E. HHC files including HHC files that include other HHC
files and so on.
Merging of Index and ALink keywords. This does not work recursively, because they do not know about the TOC inclusions. If
you want to have a unified Index or cross-module ALinks you have to
tell every CHM file which others might be available belonging to the
same project. Again: Do not merge yourself.
Another idea: If you have identical keywords from several files, HTML Help uses the <title> tags in the list of targets. We extended
the title of each topic with the title of the module itself (the
"book"), leading to: <title>This fine topic title (This fine book
title)</title>.
An include statement in a HHC file can refer to a standalone HHC file. The HHC file should be placed in the same folder as the CHM
files.
I am currently working on a simple tower defense game for iOS (using objective-c), which contains several maps/levels. However, as it is now, each map consists of an image file and a .plist file with information. My question is: is there any way I could create a custom file type (for example, *.map) that contains both the image and the information from the plist?
If this is possible, how do I implement this?
Thanks in advance!
You have several good choices for that:
The simplest solution would be grouping the related files in subfolders: rather than having xyz.map file, you could have an xyz sub-folder, and reference the files out of it. You would not need to use any additional libraries for this, and you would be able to use the same name for all your image files and all your level files, because they would be in separate folders.
You can make a zip archive with the files that you would like to combine, and unzip it before use. Here is a link to an answer referencing a library to do it.
You can use a tar format - here is a list to an answer referencing a library that supports it. You would be able to use tar utility on OS-X to group images with plists on your workstation.
Finally, you can define a format of your own: store the length of the first file in the first four bytes, then store the content of the first file, and then the second. You would need to write a utility for combining the two files into one. This sounds like the hardest choice to implement.
I have a small perl script that I use to search archives for members matching a name. I'd like to enhance this so that if it finds any members in the archive that are also archives (zip, jar, etc) it will then recursively scan those, looking for the original desired pattern.
I've looked through the "Archive::Zip" documentation, and I thought I saw how to do this. I noticed the "fh()" and "readFromFileHandle()" methods. However, in my testing, it appears that the "fh()" call on an archive member returns the file handle for the containing archive, not the member. Perhaps I'm doing it wrong, but I would appreciate an example of how to do this.
You can't read the contents of any sort of archive member (whether it is text, picture, or another archive) without extracting it from the archive file.
Once you have identified a member that you want to view, you must call extractMember (or, more likely, extractMemberWithoutPaths if the file is to be temporary) to extract it to a disk file. Then you can create a new Archive::Zip object and read the new file while keeping the old one open.
You will presumably want to unlink the archive file once you have catalogued its contents.
Edit
I hadn't come across the Archive::Zip::MemberRead module before. It appears you were on the right track with readFromFileHandle. I would guess that it should work like this, but it would be awkward for me to test it at present.
my $zip = Archive::Zip->new;
$zip->read('myfile.zip');
my $zipfh = Archive::Zip::MemberRead->new($zip, 'archive/path/to/member.zip');
my $newzip = Archive::Zip->new;
$newzip->readFromFileHandle($zipfh)
I know there's a way to make the enter-key on the keyboard confirm the inputdlg() dialog, see here:
http://www.mathworks.de/support/solutions/en/data/1-39UWQT/index.html?product=ML&solution=1-39UWQT
Okay it's a workaround, the problem is, I have to store it in the matlab directory (because as said on the page: "Since it is dependent on several private functions, newid.m will only work if stored in this location.").. The problem now is, I want to make a code which doesn#t rely on user changes in the Matlab directory because of missing privileges... Is there still another (perhaps dirty) way to achieve this behaviour?
Thanks!
Solution:
Copy the newid.m from http://www.mathworks.de/support/solutions/en/data/1-39UWQT/index.html?product=ML&solution=1-39UWQT to a arbitrary folder, e.g. into your projects folder
Go into the folder where the original inputdlg() is stored; you can find this out via which inputdlg (e.g. C:\Program Files\MATLAB\R2011b\toolbox\matlab\uitools\inputdlg.m)
Go into the private-subdirectory and copy the two files getnicedialoglocation.m and setdefaultbutton.m and paste them into your project's folder where the newid.m is located. Now call all your input dialogs by using newid() instead of inputdlg()