Hi all,
I couldn't find any previous posts on this, so here goes...
I want to copy about 300 files burried within numerous subdirectories to another location (maybe as a flat structure or maybe maintaining the same folder structure as the source files).
Is there a way to do this easily in xplorer2 or should I just rely on an external script or DOS batch file?
Thank you,
Daniel
multi-file copy
Moderators: fgagnon, nikos, Site Mods
Except for what it may take to locate/identify/select what files you want copied ... it's really very easy.
To make a "flat" copy:
0. Create the destination folder
1. create a scrap pane: Window | Scrap container
2. locate/find/browse-to the files, dragging the ones you want to the scrap container in #1.
3. Select them all with Ctrl+A
4. Copy them all to the destination in 0. by your favorite method:
either: 4a. Ctrl+C then paste in destination with Ctrl+V
or: 4b. Drag & drop while holding down Ctrl
or: 4c. r-drag to destination then Copy here
or: {your own way}.
To make a structured copy, do the same 0.,1.,2.,3. except at step 4
use either Ctrl+C {or r-click | Copy},
then, at destination: r-click | Paste special | Structured scrap clips
This will maintain the relative folder structure for the copied items.
Could it be any easier?
btw - much the same info is compactly stated on p.75 of the User Manual as well as expounded upon elsewhere in the manual.
Folks really should spend time to RTFM {where "F" means "fabulous" in this case}
PS: before copying to a flat structure, it is a good idea to check for duplicate filenames & determine whether they are different, otherwise duplicates will be overwritten by each other. Use the duplicates detector in scrappane menu: Tools | Check duplicates; then rename as you wish or paste them as structured scrap clips to preserve their folder heirarchy.
PPS: If you are planning to keep this organized collection copy on your machine you don't even have to make explicit copies of the collected files if access is to be through x2 ... just save the scrap collection as a .cida file. When you open the .cida file your collection will be available at your fingertips. (saves a lot of disk space)
To make a "flat" copy:
0. Create the destination folder
1. create a scrap pane: Window | Scrap container
2. locate/find/browse-to the files, dragging the ones you want to the scrap container in #1.
3. Select them all with Ctrl+A
4. Copy them all to the destination in 0. by your favorite method:
either: 4a. Ctrl+C then paste in destination with Ctrl+V
or: 4b. Drag & drop while holding down Ctrl
or: 4c. r-drag to destination then Copy here
or: {your own way}.
To make a structured copy, do the same 0.,1.,2.,3. except at step 4
use either Ctrl+C {or r-click | Copy},
then, at destination: r-click | Paste special | Structured scrap clips
This will maintain the relative folder structure for the copied items.
Could it be any easier?
btw - much the same info is compactly stated on p.75 of the User Manual as well as expounded upon elsewhere in the manual.
Folks really should spend time to RTFM {where "F" means "fabulous" in this case}
PS: before copying to a flat structure, it is a good idea to check for duplicate filenames & determine whether they are different, otherwise duplicates will be overwritten by each other. Use the duplicates detector in scrappane menu: Tools | Check duplicates; then rename as you wish or paste them as structured scrap clips to preserve their folder heirarchy.
PPS: If you are planning to keep this organized collection copy on your machine you don't even have to make explicit copies of the collected files if access is to be through x2 ... just save the scrap collection as a .cida file. When you open the .cida file your collection will be available at your fingertips. (saves a lot of disk space)
Fgagnon,
Awesome. Thank you so much for the info! I didn't realize scrap containers were this powerful.
That said, I ended up taking this approach to creating my scrap container:
1. made a comma delimitted text list of the files that I wanted
2. pasted the list into my Find dialog, and entered a few criterias in the Additional Rules section (...to exclude certain sub-folders and what not)
4. ran the Find, and saved the output as a scrap container (*.cida file)
Because the files will be updated continuously and put in a different location (e.g. \builds\1.0.1\ --> \build\1.0.2\, etc.), I will need to "re-create" my scrap container every time there's a new build.
BTW, I noticed a limitation on the number of files you can search for in Windows Explorer. Seems it couldn't handle the full 78 filenames in my list.
Thanks for pointing me to the right location in the manual!
Daniel
Awesome. Thank you so much for the info! I didn't realize scrap containers were this powerful.
That said, I ended up taking this approach to creating my scrap container:
1. made a comma delimitted text list of the files that I wanted
2. pasted the list into my Find dialog, and entered a few criterias in the Additional Rules section (...to exclude certain sub-folders and what not)
4. ran the Find, and saved the output as a scrap container (*.cida file)
Because the files will be updated continuously and put in a different location (e.g. \builds\1.0.1\ --> \build\1.0.2\, etc.), I will need to "re-create" my scrap container every time there's a new build.
BTW, I noticed a limitation on the number of files you can search for in Windows Explorer. Seems it couldn't handle the full 78 filenames in my list.
Thanks for pointing me to the right location in the manual!
Daniel
Glad to help, Daniel.
@ noticed a limitation ... 78 filenames
I am unsure of how to understand your statement, never having tried a find with a 78 item list.
Was that a compliment for x2's find engine that it could use the list when winExpl couldn't; or was the reference to WinExpl just a typo & you were reporting that x2's filefinder won't handle that long a list?
@ builds
Off topic, but ... you might find the build checker occasionally useful.
Mark | Check build...
see pp. 93-94 in User Manual.
@ noticed a limitation ... 78 filenames
I am unsure of how to understand your statement, never having tried a find with a 78 item list.
Was that a compliment for x2's find engine that it could use the list when winExpl couldn't; or was the reference to WinExpl just a typo & you were reporting that x2's filefinder won't handle that long a list?
@ builds
Off topic, but ... you might find the build checker occasionally useful.
Mark | Check build...
see pp. 93-94 in User Manual.
The huge number indicates that probably changing the approach will simplify things. Let us know exactly what you want to do.
If you have used a pattern in naming these files (as opposed to using random names), you can use wildcards in the search command.
Another thought: rather than looking for the individual files, you can directly search for their containers (folders). To do this, leave the "folders" option ticked, and untick the "files" option.
(But to be able to do that, the folder names need to be according to a scheme)
The huge advantage of a scheme-based search is that you don't have to change the criteria each time. That means you can save the search criteria (named searches) and reuse it later.
When your search domain itself is ever-expanding with new additions, the older CIDA file is of no use. Instead, simply save the (scheme-based) search criteria and reuse it. If the top folder is still the same, you can reuse the search without any changes whatsoever.
But for a meaningful discussion on this, we need to know more specifics: your naming scheme, folder structure, what exactly you want to do with the search results, etc...
If you have used a pattern in naming these files (as opposed to using random names), you can use wildcards in the search command.
Another thought: rather than looking for the individual files, you can directly search for their containers (folders). To do this, leave the "folders" option ticked, and untick the "files" option.
(But to be able to do that, the folder names need to be according to a scheme)
The huge advantage of a scheme-based search is that you don't have to change the criteria each time. That means you can save the search criteria (named searches) and reuse it later.
When your search domain itself is ever-expanding with new additions, the older CIDA file is of no use. Instead, simply save the (scheme-based) search criteria and reuse it. If the top folder is still the same, you can reuse the search without any changes whatsoever.
But for a meaningful discussion on this, we need to know more specifics: your naming scheme, folder structure, what exactly you want to do with the search results, etc...
Thanks for jumping in, narayan.
Those were my thoughts, too -- but you put it much better than my initial reaction (suppressed), which would have been something like:
"
78 search items??? -- what is he??? 
??? "
... But I was getting tired last night, and couldn't find the right words to expand the discussion constructively in that direction. Besides, Daniel is a smart fellow, and will figure these things out as he takes time to read the User Manual and becomes more familiar with the tools.
Daniel,
Please continue to post your questions and describe what you are doing. It is helpful to the user community at large to see real examples and solutions discussed for these kinds of file management tasks. And you might get some new ideas too.
x2 is so powerful, and has so many ways of doing things that not every way of approaching every file management task can be described in the manual.
Thanks,
-Fred-
Those were my thoughts, too -- but you put it much better than my initial reaction (suppressed), which would have been something like:
"
78 search items??? -- what is he??? ??? " ... But I was getting tired last night, and couldn't find the right words to expand the discussion constructively in that direction. Besides, Daniel is a smart fellow, and will figure these things out as he takes time to read the User Manual and becomes more familiar with the tools.
Daniel,
Please continue to post your questions and describe what you are doing. It is helpful to the user community at large to see real examples and solutions discussed for these kinds of file management tasks. And you might get some new ideas too.
x2 is so powerful, and has so many ways of doing things that not every way of approaching every file management task can be described in the manual.
Thanks,
-Fred-
...about 78 files limitation -- it was a compliment to xplorer2. xplorer2 handled the 78 file search w/flying colors. Windows Explorer, on the other hand, returned hits for only about 30 files.
...about builds -- Yes, I was looking at this, but for the moment, it's not useful to me. I only deal with the binaries (DLLs, EXEs, etc.) and not the source files (e.g. CPP).
As for searching for only folders instead of files...I actually do need to look for the files specifically, as I only need to grab a subset of all the files in each folder.
My structure looks something like this:
\\builds\8.00.08\ship
\\builds\8.00.08\ship\neutral
\\builds\8.00.08\ship\x86
\\builds\8.00.08\ship\x86\Resources
I'm primarly looking for DLLs that need to be localized. Although there are hundreds of DLLs throughout the different sub-folders above, *I* only need to grab 78 of them for now (these represent updated or new DLLs slated for localization). A few points:
- the number of files for loc. may go up to 80 tomorrow, 90 by next week, etc. So, I need to add files to my search criteria as developers create/update DLLs.
- I saved my search criteria by clicking the Save button on the "Find files or folders" dialog. I'm assuming this is what Narayan is calling "scheme-based" searches??
- Whenever a new build is made (NOTE: NOT the same as new files being assigned to me for localization), a new structure gets created by the build team, which looks something like:
\\builds\8.00.09\ship
\\builds\8.00.09\ship\neutral
\\builds\8.00.09\ship\x86
\\builds\8.00.09\ship\x86\Resources
- To obtain the latest binaries, I simply go to the \ship folder of the latest build and run Find, then select my saved search criteria from the Predefined drop-down list.
- The only purpose in saving my scrap container is that it's immediately useful and available in between builds (occur about once a week) and new binary localization requests (also about once a week).
This seems to work great for me, so far.
The end goal is to copy the files from my search results (scrap container) into my own local workspace, where I carry out my localization work using a tool called LocStudio (software localization tool, similar to Alchemy Catalyst).
Developers --> Build team --> Localization team (me) --> translators
Thanks to all for your input!
Daniel
...about builds -- Yes, I was looking at this, but for the moment, it's not useful to me. I only deal with the binaries (DLLs, EXEs, etc.) and not the source files (e.g. CPP).
As for searching for only folders instead of files...I actually do need to look for the files specifically, as I only need to grab a subset of all the files in each folder.
My structure looks something like this:
\\builds\8.00.08\ship
\\builds\8.00.08\ship\neutral
\\builds\8.00.08\ship\x86
\\builds\8.00.08\ship\x86\Resources
I'm primarly looking for DLLs that need to be localized. Although there are hundreds of DLLs throughout the different sub-folders above, *I* only need to grab 78 of them for now (these represent updated or new DLLs slated for localization). A few points:
- the number of files for loc. may go up to 80 tomorrow, 90 by next week, etc. So, I need to add files to my search criteria as developers create/update DLLs.
- I saved my search criteria by clicking the Save button on the "Find files or folders" dialog. I'm assuming this is what Narayan is calling "scheme-based" searches??
- Whenever a new build is made (NOTE: NOT the same as new files being assigned to me for localization), a new structure gets created by the build team, which looks something like:
\\builds\8.00.09\ship
\\builds\8.00.09\ship\neutral
\\builds\8.00.09\ship\x86
\\builds\8.00.09\ship\x86\Resources
- To obtain the latest binaries, I simply go to the \ship folder of the latest build and run Find, then select my saved search criteria from the Predefined drop-down list.
- The only purpose in saving my scrap container is that it's immediately useful and available in between builds (occur about once a week) and new binary localization requests (also about once a week).
This seems to work great for me, so far.
The end goal is to copy the files from my search results (scrap container) into my own local workspace, where I carry out my localization work using a tool called LocStudio (software localization tool, similar to Alchemy Catalyst).
Developers --> Build team --> Localization team (me) --> translators
Thanks to all for your input!
Daniel
Please excuse the overly elaborate answer: I am sure you would know most of this. It is just that on such occasions we also aim to answer the (unexpressed) doubts of many users. (Rather than getting scraps of information, they get end-to-end solution. That keeps down the number of posts at the forum; making it more readable.)
****************
To continue the discussion-
Actually I used the phrase "scheme-based searches" in colloquial sense: what I meant was, if your file names and directory structure are based on a scheme, you can make use of path names and folder names in your searches (using the "Additional Rules" section). That makes the search extremely powerful.
The patterns for filenames and directory structure are usually defined in your organization's Coding Standards. Rather than using individual names in searches , use these patterns.
For example, let us say your strategy is like this-
a. Maintain a list of all dlls awaiting localization (as a CIDA file)
b. Search for new dlls each week and add the results to the saved CIDA file
c. As you localize each dll, remove it from the CIDA file, and save the file again.
Here is the process (refer to the User Manual for details):
1. Specify your domain in the Look in area. If you don't want the search to go in certain folders, specify these folders with a - sign.
2. use "*pattern*.dll" as your search criteria (not all files by name). Unselect the Folders checkbox.
3. Create an additional rule.
>> In the properties and description pull-down menu, select Path[S].
>> In the Find box, enter \ship
>> Press OK to create the rule.
4. Create a second additional rule.
>> In the properties and description pull-down menu, select Modified[S].
>> Use the controls given below to specify the period after your last scan (i.e. which is about a week in your case)
(You should specify a slightly longer period overlapping the earlier scan period, to avoid missing any files. Even if there are some duplicate files, when you add the new list to the saved CIDA file, it simply ignores the duplicates.)
>> Press OK to create the rule.
5. Press Save and specify a name.
6. Press OK to run the search. The results are listed in a new scrap pane.
7. Now is the time to remote files picked up from folders for the earlier builds (your date constraint will mostly ensure that earlier builds are not picked up. But even then sometimes you may get more than one builds in a week. Therefore, this step is to weed out the earlier builds.)
>> Change the display to Details view
>> sort on path (if the Path column is not there, use the ALT+K command).
>> Mass-select groups of items by paths you don't want, and remove them from the scrap pane.
8. Weed out other undesired items.
9. In your first iteration, save this pane as a CIDA file.
>> In the subsequent iterations, simply open that CIDA file. Select all new search results and drag-n-drop them in the saved CIDA file. (It ignores duplicates.) Save the file again.
10. Now you are ready with the list. You can directly CTRL+DoubleClick on any dll to load the corresponding folder in the active pane of x2. Then proceed with localization. Once finished, remove the dll from the list and save the CIDA again. (You don't have to remember this: x2 prompts you to save a CIDA file if it is changed.)
*******************************************************
Another idea: If you are working at multiple dlls at a time, then probably you might want to create a CIDA file called WorkInProgress ("WIP.cida").
Whenever you are organizing (say once a week), load both CIDA files in opposite panes of a scrap container.
Every time, select some dlls and transfer them to WIP.cida. Once you are through with any dll, remove it from WIP.cida.
****************
To continue the discussion-
Actually, no. That is what we call "saved searches". Since a saved search takes on a name, you could call it a "named" search also.I saved my search criteria by clicking the Save button on the "Find files or folders" dialog. I'm assuming this is what Narayan is calling "scheme-based" searches??
Actually I used the phrase "scheme-based searches" in colloquial sense: what I meant was, if your file names and directory structure are based on a scheme, you can make use of path names and folder names in your searches (using the "Additional Rules" section). That makes the search extremely powerful.
The patterns for filenames and directory structure are usually defined in your organization's Coding Standards. Rather than using individual names in searches , use these patterns.
For example, let us say your strategy is like this-
a. Maintain a list of all dlls awaiting localization (as a CIDA file)
b. Search for new dlls each week and add the results to the saved CIDA file
c. As you localize each dll, remove it from the CIDA file, and save the file again.
Here is the process (refer to the User Manual for details):
1. Specify your domain in the Look in area. If you don't want the search to go in certain folders, specify these folders with a - sign.
2. use "*pattern*.dll" as your search criteria (not all files by name). Unselect the Folders checkbox.
3. Create an additional rule.
>> In the properties and description pull-down menu, select Path[S].
>> In the Find box, enter \ship
>> Press OK to create the rule.
4. Create a second additional rule.
>> In the properties and description pull-down menu, select Modified[S].
>> Use the controls given below to specify the period after your last scan (i.e. which is about a week in your case)
(You should specify a slightly longer period overlapping the earlier scan period, to avoid missing any files. Even if there are some duplicate files, when you add the new list to the saved CIDA file, it simply ignores the duplicates.)
>> Press OK to create the rule.
5. Press Save and specify a name.
6. Press OK to run the search. The results are listed in a new scrap pane.
7. Now is the time to remote files picked up from folders for the earlier builds (your date constraint will mostly ensure that earlier builds are not picked up. But even then sometimes you may get more than one builds in a week. Therefore, this step is to weed out the earlier builds.)
>> Change the display to Details view
>> sort on path (if the Path column is not there, use the ALT+K command).
>> Mass-select groups of items by paths you don't want, and remove them from the scrap pane.
8. Weed out other undesired items.
9. In your first iteration, save this pane as a CIDA file.
>> In the subsequent iterations, simply open that CIDA file. Select all new search results and drag-n-drop them in the saved CIDA file. (It ignores duplicates.) Save the file again.
10. Now you are ready with the list. You can directly CTRL+DoubleClick on any dll to load the corresponding folder in the active pane of x2. Then proceed with localization. Once finished, remove the dll from the list and save the CIDA again. (You don't have to remember this: x2 prompts you to save a CIDA file if it is changed.)
*******************************************************
Another idea: If you are working at multiple dlls at a time, then probably you might want to create a CIDA file called WorkInProgress ("WIP.cida").
Whenever you are organizing (say once a week), load both CIDA files in opposite panes of a scrap container.
Every time, select some dlls and transfer them to WIP.cida. Once you are through with any dll, remove it from WIP.cida.
Nice tutorial, Narayan
The pattern part may not be especially useable for Daniel's case.
The use of "*pattern*" presumes that a useful one can be constructed.
However, when dealing with other folks' output over which one has no control of naming convention, that is more unlikely than not.
Here, a brute-force list of dll filenames is the most efficient way to go from the user point of view. No need to risk whether a filter rule misses an item or incudes extras that need to be culled by hand.
(A list is simple to construct and easily checked; whereas a rule requires abtract pattern awareness, testing to validate, and can be hard to determine sufficiency when the target members are changed.)
It certainly is a nice idea if the team can decide to name all dll's requiring localization with a unique suffix such as uloc (for unlocalized), and which is easily findable with *uloc.dll .
Daniel could use the suffix to _loc for what he's done, and the translators can use eng, sp, deu, fr, urd, etc... for individual translations.
However, the naming convention is probably in legacy-mode, having been established years ago, and must be continued for compatibility with prior builds.
So, while a long list may seem onerous at first ...
(I had thought so until Daniel explained his context),
I now see it as a low-risk, user-efficient way to assure getting every file he needs with no duplication.
(& especially since x2's Find files... can support such a long list)
{edit/spelling corrections ... }
The pattern part may not be especially useable for Daniel's case.
The use of "*pattern*" presumes that a useful one can be constructed.
However, when dealing with other folks' output over which one has no control of naming convention, that is more unlikely than not.
Here, a brute-force list of dll filenames is the most efficient way to go from the user point of view. No need to risk whether a filter rule misses an item or incudes extras that need to be culled by hand.
(A list is simple to construct and easily checked; whereas a rule requires abtract pattern awareness, testing to validate, and can be hard to determine sufficiency when the target members are changed.)
It certainly is a nice idea if the team can decide to name all dll's requiring localization with a unique suffix such as uloc (for unlocalized), and which is easily findable with *uloc.dll .
Daniel could use the suffix to _loc for what he's done, and the translators can use eng, sp, deu, fr, urd, etc... for individual translations.
However, the naming convention is probably in legacy-mode, having been established years ago, and must be continued for compatibility with prior builds.
So, while a long list may seem onerous at first ...
(I had thought so until Daniel explained his context),
I now see it as a low-risk, user-efficient way to assure getting every file he needs with no duplication.
(& especially since x2's Find files... can support such a long list)
{edit/spelling corrections ... }
Last edited by fgagnon on 2004 Sep 16, 18:58, edited 1 time in total.
Thank you so much for the explanation Narayan. This approach will definitely have its use in other areas of my work.
For my current purposes, though, fgagnon is correct in saying that simply searching for the explicit filenames is the sure way to go. Constructing the list is easy, adding files is easy, and verifying my scrap container hits is easy.
On another note, it would be nice if the website for this product contained case studies and tutorials, not to mention a ready made template for how to propose it to management (I'm slowly putting one together; using xplorer2 clandestinely meanwhile).
You know, there are some products that have achieved "must-have" status among power users, developers, etc. One such is Beyond Compare. I'm surprised xplorer2 is still so unknown. ...have yet to meet someone else who has even heard of it. ...hmm, probably a discussion for a different thread.
Daniel
For my current purposes, though, fgagnon is correct in saying that simply searching for the explicit filenames is the sure way to go. Constructing the list is easy, adding files is easy, and verifying my scrap container hits is easy.
On another note, it would be nice if the website for this product contained case studies and tutorials, not to mention a ready made template for how to propose it to management (I'm slowly putting one together; using xplorer2 clandestinely meanwhile).
You know, there are some products that have achieved "must-have" status among power users, developers, etc. One such is Beyond Compare. I'm surprised xplorer2 is still so unknown. ...have yet to meet someone else who has even heard of it. ...hmm, probably a discussion for a different thread.
Daniel
@ case studies / tutorials / template {etc.}
All excellent ideas -- some have been suggested before.
However, currently this is only a part-time, one-man-plus-volunteers operation. So far the collection of relevant material is sparse, and nobody has volunteered to put together what we have ... other than the fabulous manual.
All excellent ideas -- some have been suggested before.
However, currently this is only a part-time, one-man-plus-volunteers operation. So far the collection of relevant material is sparse, and nobody has volunteered to put together what we have ... other than the fabulous manual.
Fred, you are right-- the pattern part is possible only if the organization has a naming convention.
But then if Daniel is only looking for dll's, then there is hardly any need for entering patterns.
***
Daniel, on the other hand, I should think there is no need to search for specific names, either--At least, now that you have already got a list. What you need is only the weekly addenda for that list. By restricting your catch by Name=*.dll and modified date=in last 7 days, you will anyway get a very slim list. Picking the right ones from that tiny list would be dead easy.
Of course, you know your situation better; but I would not recommend that torturous method to any x2 user!
***
@use cases:
The User Manual is updated with all the "tutorials" and use cases. The current version is fatter by 20 pages, PLUS a lot of existing text is revised to accomodate new tips and cautions. It should be out with the next version of x2--Probably somewhere in November.
But of course I wholeheartedly support the idea of having these tutorials online. That way, users don't have to wait till the next version of User Manual is published.
In fact, I would go to the extent of having a WIKI aboard, if our good host Sal allows that.. Let the users themselves create a masterpiece through collaborative effort.
But even with the existing board, users can publish their own tutorials. Why don't you start some yourself? Let us see if that starts a wave!
Then, once we have a respectable number of tutorials, Nikos can move them to a separate "Tips and Tutorials" area.
In a new thread, begin the subject line with "TIP:" or "TUTORIAL:", followed by the subject. Let others comment on it and add their flavors (subcases). When the idea is mature, it will find a place in the next version of the User Manual!
But then if Daniel is only looking for dll's, then there is hardly any need for entering patterns.
***
Daniel, on the other hand, I should think there is no need to search for specific names, either--At least, now that you have already got a list. What you need is only the weekly addenda for that list. By restricting your catch by Name=*.dll and modified date=in last 7 days, you will anyway get a very slim list. Picking the right ones from that tiny list would be dead easy.
Of course, you know your situation better; but I would not recommend that torturous method to any x2 user!
***
@use cases:
The User Manual is updated with all the "tutorials" and use cases. The current version is fatter by 20 pages, PLUS a lot of existing text is revised to accomodate new tips and cautions. It should be out with the next version of x2--Probably somewhere in November.
But of course I wholeheartedly support the idea of having these tutorials online. That way, users don't have to wait till the next version of User Manual is published.
In fact, I would go to the extent of having a WIKI aboard, if our good host Sal allows that.. Let the users themselves create a masterpiece through collaborative effort.
But even with the existing board, users can publish their own tutorials. Why don't you start some yourself? Let us see if that starts a wave!
Then, once we have a respectable number of tutorials, Nikos can move them to a separate "Tips and Tutorials" area.
In a new thread, begin the subject line with "TIP:" or "TUTORIAL:", followed by the subject. Let others comment on it and add their flavors (subcases). When the idea is mature, it will find a place in the next version of the User Manual!
@ think there is no need ...
I think you misunderstand that it is ony a fraction of the hundreds of new .DLLs that need localisation work. So a list IS the best way to go.
@ in a new thread
GOOD IDEA !!
{btw -- I did not mean to imply there was no tutorial info in the manual -- only that it wasn't separately organised on the web site or board.}
I think you misunderstand that it is ony a fraction of the hundreds of new .DLLs that need localisation work. So a list IS the best way to go.
@ in a new thread
GOOD IDEA !!
{btw -- I did not mean to imply there was no tutorial info in the manual -- only that it wasn't separately organised on the web site or board.}