Clip naming convention upon import

Is there a way to use the date of the clip as its name upon import, instead of Clip01, Clip02,... If there are more than one clip for a given date, it could be something like 20061102-1. 20061102-2 etc... Anyone knows if it can be done?

You can of course change the name of the clips, after
import, in the same way as you would change the name
of any folder.
Don't misunderstand what Klaus1 says. iMovie lets us change the name of CLIPS in iMovie. But we cannot change the name of the FILES the clips rely on without corrupting the project.
Changing the name of a clip does not change the name of its source file. iMovie keeps track of which clip goes with which file. It doesn't like it when we mess with the file name.
Karl

Similar Messages

My iMovie project staggers/skips over my transitions...I read that I need to optimize each clip. I did this individually and it worked but was time consuming. Is there a way to optimize all of my clips at once upon import?

My iMovie project staggers/skips over my transitions...I read that I need to optimize each clip. I did this individually and it worked but was time consuming. Is there a way to optimize all of my clips at once upon import?

When you import, the import screen should give you the option to optimize clips. Select Optimize - Full Size.
I think you can also right-click on the Event Name and it will let you optimize all clips in the Event, but I haven't tried it lately.

Portal items - naming conventions

Hi,
I'm curious to hear of the naming convention that you folks use for your Portal.
When creating a remote portlet for example, I'll need to create a webservice and a portlet, so I might name them like this (assume this is a small calendar portlet):
My Calendar - Web service <-- for the web service
My Calendar - Portlet <-- for the portlet
But then I wonder if I even need the "Web service" and "Portlet" text as these are usually clear from the context.
As someone with very little experience with ALUI I'm keen to hear what others have done and how its worked out.
Thanks,
James.

Hello James...
Here are a few examples of some of the naming conventions we employ:
1. We add " Web Service" to the end of the name of each web service. When the web service is only used to instantiate one portlet, we name the web service <Portlet Name> Web Service. When it can be used to instantiate many portlets (e.g. has an accompanying template), we name the web service <Descriptive Name> Web Service.
2. We give portlets a concise and descriptive name. The name of the portlet shows up in its title bar when it is displayed on a page (unless you hide the title bar), so using a convention like <Descriptive Name> - Portlet would add extranneous information to that title, decreasing usability.
3. We add "Job" to the end of the name of each job operation - mainly to increase effectiveness of Admin Object Search when configuring the Automation service
4. We name admin folders that contain crawlers and jobs <Descriptive name> Crawlers and Jobs - again, to increase effectiveness of Admin Object Search when configuring the Automation service
Naming conventions are important, but they become more important with more distributed portal deployments. If you allow community managers to access administration and let them create their own admin objects, you'll want to have some governance in place that explains the rules (without making them so complicated they become an annoyance).
My two cents... Hope it helps...
Danya
Portal Administrator
Lear Corporation
Edited by: Danya D. Smith on Sep 16, 2008 9:03 AM

Is it possible to control the naming convention used by Aperture when importing photos? If so, how

When I import photos from my camera, I have them placed into projects based on the date the photos were taken. However, I do not like the naming convention used by Aperture as it causes the projects to sort into a non-chronologial order. The convention is MMM-DD-YYYY and I want to change it to YYYY-MM-DD. Is it possible in Aperture 3.2.4 to do this?

In the Import panel you can edit the preset for the file name format to "Image year - image month - image day - index" for example; the preset for folder names seems to be gone in Aperture 3,3 - at least I cannot find it any longer. You only seem to be able to enter the folder name manually in the Import panel.

Export-Import and Naming convention question

All,
Newbie here. Have a question related to the naming convention for SAP R/3 system and XI manual export/import process. We are currently in the development environment where our R/3 systems are named as D55CLNT400, D56CLNT300 etc (first 3 characters are the system id, and last 3 are the client number.) This is per the XI best practices convention.
The question i have is - if we name the technical system as above - and export the configuration objects from the Dev to Test environment - where the R/3 systems are named as T55CLNT400, T56CLNT300 (similar naming structure). Does it mean that we need to manually change almost all of the items in the Test environment on the configuration side (like business sytem name, interface determination, receiver determination etc)
Is this the correct way or are we missing something??? I would have preferred a way - where we needed to only update the communication channel parameters.
Thanks.
Message was edited by:
thezone

In the SLD, create three Business System Groups: DEV, QAS and PRD.
In each of these groups, you must have the relevant application servers (in your case, R/3s) and one integration server (XI).
Then, for each Business System in Group DEV, define a transport target in QAS group.
In your case, the transport landscape should be like this:
D55CLNT400 -> T55CLNT400
D56CLNT300 -> T56CLNT300
XI_DEV -> XI_QAS
Do the same for the QAS group (defining transport targets in PRD group). Observe that you need to have the same number of Business Systems in each group for this to work properly.
Now, when you transport your configuration objects from XI_DEV to XI_QAS, all the Business Systems in DEV landscape will be replaced for the equivalent ones in QAS landscape.
More info: http://help.sap.com/saphelp_nw2004s/helpdata/en/ef/a21e3e0987760be10000000a114084/frameset.htm
Regards,
Henrique.

Lumix GH4 - AVCHD clips 16.5 hours in the past upon import.

I have a Panasonic Lumix GH4 (firmware V2.0). I just discovered that all my clips shot in AVCHD have an incorrect creation date upon import into FCPX (10.1.4). All files have a creation time/date exactly 16 hours and 30 minutes behind the actual recording time.
The clock on my camera is correct time. The date shows as being correct when I review the clips on the GH4. But when importing to FCPX, the date in the media import window shows the creation date as exactly 16.5 hrs in the past. I have tried this on my Macbook Pro, iMac and just returned from the local Apple store where I tried it on their Mac Pro, with a Genius observing the process. Exact same result.
This ONLY occurs when the clips are AVCHD format. The GH4 offers AVCHD, MP4, MOV. All clips shot in mp4 or mov show the correct creation date. It is only the AVCHD clips that have this issue.
For example, if is shoot short 3 clips at exactly noon (12:00pm) today. Quickly switching the format between the clips. Upon import to FCPX the mov and the mp4 show a 12:00pm January 26 creation date. The avchd clip show 5:30pm, January 25 date.
This makes a total organizational mess when I have dozens of multi cam clips from other cameras that do sort properly by date.
Has anyone else seen this ?

Would someone mind just shooting a few seconds of video in AVCHD, pop out the SD card, and import media into FCPX and check the Creation date please. Any results would be appreciated. (BTW: This has to be v2.0 of the GH4 firmware).
The attached pic are the Get Info on 3 files shot seconds apart. ACVHD, MP4, MOV. Note the creation dates.

Private vs. protected, naming conventions etc.

I've been grappling with a couple of frustrations with Forte, and I'm
interested in feedback from others on this list regarding approaches
they may have adopted to address these.
One is that in the Forte workshops there is no way to view only the
public methods and attributes of a class (we're still using V2 here; I'm
assuming that V3 has not changed this). While referring to appropriate
technical documentation for a class is obviously important, I still find
myself opening up classes in the workshops to inspect the methods and
attributes available. (What I really want to see is an integrated class
browser. I sure hope Forte is working on something like this, or will
open up their development environment to support third-party extensions.
But that's an aside.)
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. Again, I'd be very interested in hearing how others have dealt
with this issue.
Thanks.
Michael Brennan
Programmer/Analyst
Amgen Inc.

I sent this once before, but the list seemed to be having trouble late last
week. If you get two copies of it... my apologies.
OK, I couldn't resist joining the fray...
At 10:56 AM 11/6/97 -0800, Michael Brennan wrote:
>
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.You might even designate a single character before the underscore to denote
that, just in case some environment (CORBA) doesn't like the "_". You could
make it something like "Q" or "Z" or something that wouldn't normally be
used alone at the start of a name.
>
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. I share your desire for protected methods, but I have to disagree about
protected attributes. Philosophically speaking, protected and public
attributes are EVIL!! (I say "philosophically speaking" because, in the
Forte environment, there are some valid reasons for using them based upon
the visibility constraints of the language. In other languages, C++ and
Java, for example, it's not even philosophically speaking - they're just
evil!!)
One of the principal reasons for adopting the object paradigm is to
tightly control the impact of change - to provide good boundaries of
encapsulation that change does not ripple beyond. If you think about it,
one of the measures of the success of a superclass is the number of
subclasses that it has (especially for a good dabstract interface). This
says you have very nicely captured the semantics of the application domain
in the interface of the superclass. So, let's imagine a superclass with
protected attributes that are used by each of its 100 subclasses (probably
more than you would have, but I'm illustrating my point - incidentally, I'm
not talking about a hierarchy 100 deep; I'm talking about 100 subclasses
that are all direct decendants of the superclass). Now you go and change
one of the attributes. You must go look at all 100 subclasses to determine
the impact of change. This is exactly the kind of thing the object paradigm
was designed to eliminate.
Protected methods, on the other hand, would be nice.
And At 12:06 PM 11/6/97 -0800, Mark S. Potts wrote:
>
Forte inherits in a strange way when attributes are private. A
superclass attribute that is made private is not accessible from any of
its subclasses - this means that many of what you would consider private
attributes in fact have to be public. Well, the definition of private means "not visible outside of the class
where it is defined". I find it useful to think of the level of visibility
the same as secrets. There are things that are not really secrets at all -
it's ok if anyone knows them ("My name is Stephen"). These are public.
Then, there are things that it's ok if my family knows, but I don't want
the world to know - familial secrets, if you will ("I belch at the dinner
table when I'm at home"). These are visible to descendant classes and we
call them protected. Finally, there are things we don't want anyone else
to know, no matter who they are ("I poisoned my mother-in-law"). These are
private. We don't want anyone outside of ourselves to know these things.
These are the classic definitions of public, protected and private (perhaps
classic only because C++ defined them that way and everyone else just
copied what it meant).
Private attributes are not meant to be inherited by their subclasses.
That's why they're private. And, yes, I would argue that that is completely
correct. What you want, if you want them to be visible to subclasses, is
"protected". Now, Forte doesn't support protected, but that's a different
arguement - perhaps even an enhancement request.
We also should not confuse what we need to do in a language/environment
with what good OO principles are. For example, good OO design principles
state that you do not have public or protected attributes. Period! You
access them via accessors and mutators defined on the appropriate class.
Now, in some environments, this will not give you the performance you need,
so you open things up a bit. But, you shouldn't convince yourself that
doing this is the ideal design, just that it was necessary for performance.
The real problem here is that the performance of accessor and mutator
functions is not fast enough. That's why we open it up. Not because it is
good design. The proper way to fix the problem is to make accessors and
mutators fast enough so that they can be used (C++, for example, does this
with "inline" - not that C++ is my favorite language, it's not. But they
have fixed this one area nicely.)
Some would argue that this is correct and that inheritance does break thepure rules
of encapsulation I don't think inheritance, properly handled (and Forte does properly
handle it) breaks any rules of encapsulation. I would argure that the way
they treat private attributes is quite correct.
- but these people dont build applications!Hmmm... let's see... started building OO applications in 1985 (and building
them ever since) in complex application domains like CAD/CAM/CAE, Air
Traffic Control, Graphics/Imaging, Telecommunications, e-commerce,
entertainment,... ...wrote (and teach) the Forte OO Analysis and Design
course.
I guess you're right. I don't build applications. I build robust,
maintainable, extendable applications. ( ;-) ...nudge, nudge!)
Stephen

Cannot get proper naming extension upon saving

I'm frustrated with not having the proper extension on the name at the end of saving from FC. I go to import in DVD Studio Pro and upon choosing "import" the files compressed by Compressor only say, "compressor" at the end instead of mpeg-2 or sound, etc.
Please advise. Thank you

Ok, I appreciate your patience with me. First I must mention I'm trying to do this project at home after I get back from work but I am now replying to you from work so I may get my facts off a tad.
As best I know, since I have produced a video in FC of a skater, based on what I've studied, it's preferable to compress it with a two pass VBR as opposed to simply a quicktime mov file. My understanding is that because of the constant movement (and the fact that this is my first ever effort at this and it's for a client) I'll get a better product going with the 2pas (MPEG-2) file.
The six minute video takes about two hours to render this way and I've attempted it three times.
Finally las night because of non success I reverted to producing a mov. and took it to Studio Pro and at about 1a.m. got a finished product and left it on the client's doorstep. She is happy with it, but I know I can do better. She is going to want more and I'm wanting to improve.
My problem seems to be that I'm messing up the naming convention or something. I believe the files all end with the word, "compression" instead of .MPEG-2. I did find through trial and error that I needed both a sound file and the video file. And I do know I'm close but I was so sure last night at about midnight it was going to work... and it didn't.
Will try again tonight when I get home. Sorry this is so long... So is my project (ha).

.tpz files naming convention / export from PI 7.0

Hi,
When I export the repository or Directory content from PI 7.0 the naming convention PI gives its own naming convention. Starting wit XI3_0 * .tpz
Why does it start with XI3_0*.tpz for we have PI 7.0?
Do we need to change any Visual admin or exchange profile parameter to get the naming convention to PI7_0*.tpz
Thanks
Sachin

Hi,
The import and export functionality of XI 7.0 uses the expression 'XI 3.0' instead of 'XI 7.0' in all transport screens of the Integration Builder. Furthermore the name of XI 7.0 exports will always start with the prefix 'XI_3_0' and not 'XI_7_0'.
Reason and Prerequisites
The reason for this behaviour is that the transport code and format of XI 7.0 and XI 3.0 is identical.
Solution
There is no fix for the naming convention, but there is a positive consequence: XI 3.0 export files can be produced by XI 3.0 and XI 7.0 and can be imported into XI 3.0 and XI 7.0.
Refrence Note
Note 936254 - XI 3.0 Imports and Export in XI 7.0
Award points if helpful.
Thanks,
Tanuj

Hard to find ripping naming conventions

?In Mediasource Player 3.3, I had a really hard time finding the naming convention settingsdialog. It is in the media folder format settings option. I ended up with a bunch of ripped tracksthat had the track name twice and couldn't find the option. Hopefully this thread will help someoneso they don't have to struggle as much as I did. In the Settings pop-up the PC Music Library tab,and the Properties button under the first item which is the name of your current PC Music libraryname. I had failed to change the last box on the bottom right from track name to none. Ta paj692

I guess the argument against your argument is that your code should be as self-documenting as possible. In your code, I'll see "Event". Great. java.awt.Event? No (annoyance #1 already). Your base Event? I wouldn't know, need to check the imports first. Aaahh, scrolled up and saw: your special implementation Event it was. Although, I will not see that if I'm not familiar with your package structure and you're doing package imports.
Create packages for functional groups, otherwise you'll end up with loads of unnecessary public declarations because your helper classes are splattered all over the place and can't just rely on in-package visibility.
And by the way, using polymorphism properly like you don't seem to do, you'll screw yourself, because you'll in future have to do things like:
Event ev = new com.mystuff.special.implementation.Event();Because you can't import both the interface/superclass and the implementation. Congratulations.

Best practices in Internal table naming convention GT , GS , LT , LS ??

Hi Gurus,
 Are GT_ , GS_ , LT_ , LS_ --- the Best practices in Internal table naming convention ????
 I have seen this naming convetions adhered in standard programs .
 What each one of the below signify
 GT_ , GS_ , LT_ , LS_ ???????
Regards
Jaman
Message was edited by:
 ABAP Techie

Hello
I use the following naming conventions:
- G = global variable
- L = local variable
- T = internal table
- S = structure
- D = field
That's how the combinations look like:
- GT_ITAB = global itab
- GS_STRUC = global structure
- GD_FIELD = global field
- LT_ITAB = local itab
- LS_STRUC = local structure
- LD_FIELD = local field
Function module parameters have to stick to the following rules:
- I = importing
- E = exporting
- [C = changing -> never used]
- IT_ITAB = imported table type (itab)
- IS_STRUC = imported structure
- ID_FIELD = imported field
- ET_ITAB = exported table type (itab)
- ES_STRUC = exported structure
- ED_FIELD = exported field
Depending on their semantics TABLES parameters look like:
- IT_ITAB = imported data
- ET_ITAB = exported data
- XT_ITAB = changing data (import & export)
Here are the conventions for FORM routine parameters:
- UT_ITAB = using itab (data are usually treated like constants; no changes will be transfer - although possible - to the calling program)
- CT_ITAB = changing itab (if it is semantically an exporting itab then one of the very
first statements in the routine is: REFRESH ct_itab. )
- US_STRUCT
- UD_FIELD
- CS_STRUCT
- CS_FIELD
Conventions for class/interface parameters:
- IT_ITAB = importing table type
- IS_STRUC = importing structure
- ID_FIELD = importing field
- ET_ITAB = exporting table type
- ES_STRUC = exporting structure
- ED_FIELD = exporting field
- RT_ITAB = returning table type
- RS_STRUC = returning structure
- RD_FIELD = returning field
Conventions for class/interface attributes:
- MT_ITAB = table type
- MS_STRUC = structure
- MD_FIELD = field
- MC_CONST = constant
Question: Are there any advantages of such elaborated naming conventions?
My answer to this question is: Yes, definitively.
I believe that the advantage of semantically differentiating TABLES parameters of function modules is quite obvious:
CALL FUNCTION 'Z_BAD_NAMING'
 TABLES
 itab1 = ...
 itab2 = ...
 itab3 = ... .
CALL FUNCTION 'Z_GOOD_NAMING'
 TABLES
 it_itab1 = ...
 et_itab2 = ...
 xt_itab3 = ... .
I also believe that my naming conventions clearly enhance readability and maintainability of my programs.
Regards
Uwe

Question about Best Practices - Redwood Landscape/Object Naming Conventions

Having reviewed documentation and posts, I find that there is not that much information available in regards to best practices for the Redwood Scheduler in a SAP environment. We are running the free version.
1) The job scheduling for SAP reference book (SAP Press) recommends multiple Redwood installations and using export/import to move jobs and other redwood objects from say DEV->QAS->PROD. Presentations from the help.sap.com Web Site show the Redwood Scheduler linked to Solution Manager and handling job submissions for DEV-QAS-PROD. Point and Shoot (just be careful where you aim!) functionality is described as an advantage for the product. There is a SAP note (#895253) on making Redwood highly available. I am open to comments inputs and suggestions on this issue based on SAP client experiences.
2) Related to 1), I have not seen much documentation on Redwood object naming conventions. I am interested in hearing how SAP clients have dealt with Redwood object naming (i.e. applications, job streams, scripts, events, locks). To date, I have seen in a presentation where customer objects are named starting with Z_. I like to include the object type in the name (e.g. EVT - Event, CHN - Job Chain, SCR - Script, LCK - Lock) keeping in mind the character length limitation of 30 characters. I also have an associated issue with Event naming given that we have 4 environments (DEV, QA, Staging, PROD). Assuming that we are not about to have one installation per environment, then we need to include the environment in the event name. The downside here is that we lose transportability for the job stream. We need to modify the job chain to wait for a different event name when running in a different environment. Comments?

Hi Paul,
As suggested in book u2018job scheduling for SAP from SAPu2019 press it is better to have multiple instances of Cronacle version (at least 2 u2013 one for development & quality and other separate one for production. This will have no confusion).
Regarding transporting / replicating of the object definitions - it is really easy to import and export the objects like Events, Job Chain, Script, Locks etc. Also it is very easy and less time consuming to create a fresh in each system. Only complicated job chains creation can be time consuming.
In normal cases the testing for background jobs mostly happens only in SAP quality instance and then the final scheduling in production. So it is very much possible to just export the verified script / job chain form Cronacle quality instance and import the same in Cronacle production instance (use of Cronacle shell is really recommended for fast processing)
Regarding OSS note 895253 u2013 yes it is highly recommended to keep your central repository, processing server and licencing information on highly available clustered environment. This is very much required as Redwood Cronacle acts as central job scheduler in your SAP landscape (with OEM version).
As you have confirmed, you are using OEM and hence you have only one process server.
Regarding the conventions for names, it is recommended to create a centrally accessible naming convention document and then follow it. For example in my company we are using the naming convention for the jobs as Z_AAU_MM_ZCHGSTA2_AU01_LSV where A is for APAC region, AU is for Australia (country), MM is for Materials management and then ZCHGSTA2_AU01_LSV is the free text as provided by batch job requester.
For other Redwood Cronacle specific objects also you can derive naming conventions based on SAP instances like if you want all the related scripts / job chains to be stored in one application, its name can be APPL_<logical name of the instance>.
So in a nutshell, it is highly recommend
Also the integration of SAP solution manager with redwood is to receive monitoring and alerting data and to pass the Redwood Cronacle information to SAP SOL MAN to create single point of control. You can find information on the purpose of XAL and XMW interfaces in Cronacle help (F1).
Hope this answers your queries. Please write if you need some more information / help in this regard.
Best regards,
Vithal

Transport with CTS+ : Naming convention

Hi SDNers,
I need your suggestion.
This is wrt CTS+.
My doubt is:
I need to transport changes between the Dev, QA & Production system.
I have a repository in Development system: Repo_Dev
Now I want to create a repository in Quality / Production system, similar to Repo_Dev , but with different Repository names as Repo_QS / Repo_Prod respectively. My doubt is, will I be able to create the repositories in the Quality or Production systems with the name I want.... or is it because I am using CTS.. it will create a repository with the same name i.e Repo_Dev.
With reference to the SAP document "Setup und Use the MDM Change Transport with CTS+ Transport Management Environment", my understading is to
1. Create a repository in QS / Production side.
2. Using the option "Create Transport Reference" , I will get a reference file of Repo_Dev.
3. Then Import the reference file in the Repo_QS / Repo_Prod will result in synchronisation between all 3 (Repo_Dev, Repo_QS, Repo_Prod ) repositories.
This way I can have the same Data modelling etc in all the 3 repositories, with the naming convention as required.
If anyone has worked on it... please confirm it.
Thanks & Regards,
Priti Rani Patnaik

Hi Priti,
For transport with CTS+ you need to follow the steps which you have mentioned. You need to create a repository and then import the ref. in this repository. By doing so you are only importing the tables and fields present in your Dev repository. The sync between all three is only related to data modelling and it will not effect the name of reposiotry as you have already created a repository and I guess renaming of repository is not possible.
I hope I am able to help you.
Thanks & Regards
Dilmit Chadha

Code Inspector - Naming conventions &mExtended Naming conventions for Progs

Hi experts,
I had a look into the naming conventions enforced by 'DEFAULT' variant of code inspector (SCI).
the relevant categories are: "Naming Conventions", and "Extended Naming conventions for Programs" under "Programing conventions".
in the "Extended Naming conventions for Programs" category, for functions, (applicable while calling the functions) it says,
importing parameter : I[:type:]_
exporting parameter : E[:type:]_
changing parameter : C[:type:]_
tables parameter : T[:type:]_
but in the "naming conventions" category, for functions (applicable while defining the functions), it says,
importing parameter : P_*
exporting parameter : P_*
changing parameter : P_*
tables parameter : P_*
I felt, while defining the function too, its better to have beginning with I_, E_, C_ or T_ instead of P_
is the 'DEFAULT' variant of code inspector is provided and recommended by SAP?
for easier maintenance and clearer understanding, which naming convention is more suitable, or is there any official guidelines released by SAP for ABAP developers.
appreciate the opinions from experienced abap developers.
thanks,
Madhu_1980

Frank,
Thanks for your answer.
But what about Entity Objects, View Objects, View Links, and Application Modules.
I would like my developers to have an easy way to name them and also find them via intellisense.
So I was thinking in naming them the following way :
Entity Objects :
EO_Employee
EO_Department
View Objects :
VO_Employees
VO_Departments
View Links :
VL_EmployeesToDepartments
Application Module :
AM_HRService
However the use of "_" is not so "Java naming oriented".
So other alternatives would be:
1. take the "_" :
1.1 EOEmployee (I don't like the fact of having 3 capital letters together).
1.2 EoEmployee (I don't like the fact of having Entity Object with a lowercase "o").
2. Use the prefix at the end, but this way I loose the intellisense feature I want:
ex: EmployeeEO
Which naming approach are you using for big projects ?
Thanks,
Claudio.

Naming Convention

Hi there
I'd be interested in hearing from others who use a naming convention for their photo files. I'm planning a major reorganisation of my files & would appreciate hearing from others what's worked for them.
Thanks
Stephen

I use a fairly lengthy naming convention that predates my use of PSE's Organizer. Some characters are obviously non-essential. The others let me know what subdirectory holds the image, the date filed, and what the origin was (digital, slide, or negative). It goes like this:
Character Content
1 R (as in roll)
2-4 "roll" sequence number
5 type - D for digital, S for slide, N for negative
6 _ (underscore)
7-10 year
11-12 month
13-14 day
15 _ (underscore)
16-17 or 18 image sequence number
My subdirectories are named using the first 14 characters.
So an image gets a name like R298D_20051213_027.jpg, and if I write the file name on the back of a print, I can quickly locate the file on the hard drive, and the neg/slide in my binders/boxes. The slide/file binders/boxes are marked with the roll sequence numbers. I use a program called "Bulk Rename Utility" to rename the images before letting the PSE organizer see them. This precludes importing to PSE directly from the camera or card reader, but I don't do that for other reasons as well.
The utility may be found at www.bulkrenameutility.co.uk or www.jimwillsher.co.uk.
Hey - it works for me!

Clip naming convention upon import

Similar Messages

Maybe you are looking for