I have created labels and I have noticed an anomaly.
The file name var “pFileName“ contains the value “p#004“ although the real file name is “p#004.2_450(.sm2d)“ The var “mFileName“ does not appear to be filled at all.
Are there constraints upon the file name structure / permitted chars?
I have no idea why my text has been substituted with chars that I have not typed!
& 
Works for me.
Make sure the label is large enough to show all the lines. Also you can preview the label:
What is rather perplexing though is why the file extension does not show? 
Anybody else think we should show the file extension?
Welcome to string hell. It’s because it’s an HTML editor. It’s interpreting the 1st % char. You need to escape the % char with the slash:
%pFileName%
You also have to escape chars like < when showing tags: <groups>
Or when you want to display text in quotes "Text"
It gets real annoying in c++ as a quoted string actually has to be coded as 
So it can get confewzing:
I hadn’t considered that … 
… Thanks, noted!
Yes, I think that would be a good idea
Probably because there is (was) only one possible extension & the extension is not part of the meaning which the user has given the file.
But at the moment using that tag isn’t part of my workflow, so I can only imagine that it might be annoying either way. But there are still the Pattern Name & Pattern Number fields, & the Pattern Number is quite happy to be “bob”, so I think that gives sufficient options for anyone not wanting the extension.
There are 6 possible extensions - .val, .vis, .vst, .sm2d, smis, and .smms. IMO the label should show the extensions to give meaning to anyone else using the pattern.
I could just make it a Label preference? “Show file extensions in labels”.
Can I assume you meant the forums editor? I run into it all the time when pasting source code or snippets of pattern files… in which case the “blockquote” comes in handy as it doesn’t try to interpret anything.
%pFileName%
Ok… I feel dumb now… there already are file “extension” place holders for the pattern and mesurement files… Doh.
I probably never associated “Pattern extension” with the “Pattern file extension” and “Measurements extension” as “Measurements file extension”.
Big problem is…
Anyone see the problem?
The extensions are hardcoded, not read off the files. So they aren’t applicable to modern Seamly files.
Bingo! I made a Github issue and I’m already fixing it… will know in a few minutes when the compliler finishes.
Ok - to make it cleaer - Besides correcting the typos of “Measurments” which apparently has been there since before forking, I also added “file” to the extension item texts in the placeholder drop down:
And made all the lupdates.
And just because it was driving me nuts… I made it so the placeholder list is sorted:
It was a bit tricky as the list is not a combobox, but rather a pushbutton with a popup menu of actions, which unlike a combobox, the items are not automatically sorted when inserted.
Hi,
Just a ‘quickie’, I re-verified my usage of the ‘Label’ function, vis-à-vis the truncation of file names.
This truncation occurs at the first ‘.’ (Dot / full stop) occurrence of that character.
I assume that the originator assumed this to be the separation from the suffix OR that the coding (Qt?) does not handle the filename retrieval correctly (system call?). PS1 / Batch / Python code do this OK.
Just a remark for those of us who use permitted chars (Windows for me) in file names.
I will refer you to the Qt docs for QFileInfo which handles files names. followed by the actual code used in Seamly.
------------------------------------------------------------------------------- QFileInfo::fileName() const
Returns the name of the file system entry this QFileInfo refers to, excluding the path.
Example:
fi("/tmp/archive.tar.gz"); name = fi.fileName(); // name = "archive.tar.gz"
QFileInfo::baseName() const
Returns the base name of the file without the path.
The base name consists of all characters in the file up to (but not including) the first ‘.’ character.
Example:
fi("/tmp/archive.tar.gz"); base = fi.baseName(); // base = "archive"
QFileInfo::completeBaseName() const
Returns the complete base name of the file without the path.
The complete base name consists of all characters in the file up to (but not including) the last ‘.’ character.
Example:
fi("/tmp/archive.tar.gz"); base = fi.completeBaseName(); // base = "archive.tar"
QFileInfo::suffix() const
Returns the suffix (extension) of the file.
The suffix consists of all characters in the file after (but not including) the last ‘.’.
Example:
fi("/tmp/archive.tar.gz"); ext = fi.suffix(); // ext = "gz"
QFileInfo::completeSuffix() const
Returns the complete suffix (extension) of the file.
The complete suffix consists of all characters in the file after (but not including) the first ‘.’.
Example:
fi("/tmp/archive.tar.gz"); ext = fi.completeSuffix(); // ext = "tar.gz"
------------------------------------------------------------------------------- Code used in Seamly text maanger:
placeholders.insert(pl_pExt, QFileInfo(qApp->getFilePath()).suffix()); placeholders.insert(pl_pFileName, QFileInfo(qApp->getFilePath()).baseName());
As you may notice it uses ONLY the basename() and the suffix()… that is anything left of the 1st ‘.’, and right of the last ‘.’ respectively.
In other words a filename of “myfile.some_more_chars.ext” in the text manager will only return “myfile” for the pFileName. and “ext” for the pExt. You will never see “some_more_chars” included in the label text.
That being said… In order to not loose part of the filename, I should probably switch the code to use the complete suffix, as generally you would not include dots in a basename, but rather with multiple extensions like .tar.gz
With that being said… IMO there should be no case for using multiple dots in a Seamly pattern or measurement file name. It’s just asking for trouble. Stick to “lower_case” dot “ext” or “file-name” dot “ext”. And yes I know you can, but I recomend no upper case and no spaces in a file name.
In Unix-like systems, filenames are case-sensitive , meaning
FILE.TXTandfile.txtare considered two distinct files. The standard convention is to use all lowercase letters for file and directory names to ensure consistency, prevent issues with case-insensitive systems (like Windows), and make them easier to type in the command line.
Spaces are generally acceptable in modern operating systems like Windows and macOS (Unix-based), but they can cause issues, particularly with older software, programming scripts, and command-line interfaces. For maximum compatibility, it is often considered a best practice to avoid using them.
