Why new collection framework

can somebody tell me Why sun people has created new collection framework and restructured all the classes and interfaces?

Please refer to:
http://java.sun.com/j2se/1.4.2/docs/guide/collections/overview.html
http://java.sun.com/docs/books/tutorial/collections/index.html

Similar Messages

Why hashMap is not the part of collection framework

why hashMap is not the part of collection framework ??
why Map start its own new hierarchy??
thanks

A Map is not simply a collection of stuff, it is a mapping from stuff to stuff.
It doesn't make any sense to "add stuff to a map", unless you tell it both a key and a value.
It doesn't make any sense to ask "does this contain stuff", unless you tell it to look in its keys or in its values.
Those (and similar) reason explain why a Map is not a Collection.
Note that there are views of the keys and the values that do behave like Collections (for example you can take the keys() view of the Map and tell it to remove stuff from it and it will do what you'd expect). But the Map as a whole is not a Collection of stuff. It is a mapping of stuff.
(I hereby declare "stuff" to be a technical term).

Problem with collection names getting replaced when creating new collections in Photoshop Elements 5.0

We have been using Photoshop Elements 5.0 a lot lately to organize many photos into collections. A new problem just arose when creating a new collection.
As we named the new collection and clicked on "OK" it replaced another existing collection with the new name. The photos from the old collection were still there but now under the new collection name. This happened at least three or four times, each time a different "old" collection was renamed. Does anyone know why this would happen?
This past week we have added at least 20 new collections with no problem prior to this. Adobe actually had to shut down when this happened. Each time we reopened Adobe it would happen again randomly renaming a different "old" collection when we tried to add the new one. Any insights would be much appreciated.

Thank you - that was the problem and now it is working correctly
again!
Tom Z.
>>> saurabh288 <[email protected]> 05/24/09 4:23 AM >>>
It may be that the catalog has been corupted.Try repairing the
catalog of PSE.

Redesigning the Collections Framework

Hi!
I'm sort of an experienced Java programmer, in the sense that I program regularly in Java. However, I am not experienced enough to understand the small design specifics of the Collections Framework (or other parts of Javas standard library).
There's been a number of minor things that bugged me about the framework, and all these minor things added up to a big annoyance, after which I've decided to (try to) design and implement my own framework.
The thing is however, that since I don't understand many design specifics about the Collection Framework and the individual collection implementations, I risk coming up short with my own.
(And if you are still reading this, then I thank you for your time, because already now I know that this entry is going to be long. : ) )
Since I'm doing my Collection framework nearly from scratch, I don't have to worry too much about the issue of backwards compatibility (altough I should consider making some parts similar to the collection framework as it is today, and provide a wrapper that implements the original collection interfaces).
I also have certain options of optimizing several of the collections, but then again, there may be very specific design issues concerning performance and usability that the developers of the framework (or other more experienced Java progammers) knew about, that I don't know.
So I'm going to share all of my thoughts here. I hope this will start an interesting discussion : )
(I'm also not going to make a fuss about the source code of my progress. I will happily share it with anyone who is interested. It is probably even neccessary in order for others to understand how I've intended to solve my annoyances (or understand what these annoyances were in the first place). ).
(I've read the "Java Collections API Design FAQ", btw).
Below, I'm going to go through all of the things that I've thought about, and what I've decided to do.
1.
The Collections class is a class that consists only of static utility methods.
Several of them return wrapper classes. However the majority of them work on collections implementing the List interface.
So why weren't they built into the List interface (same goes for methods working only with the Collection interface only, etc)? Several of them can even be implemented more efficiently. For example calling rotate for a LinkedList.
If the LinkedList is circular, using a sentry node connecting the head and tail, rotate is done simply by relocating the sentry node (rotating with one element would require one single operation). The Collections class makes several calls to the reverse method instead (because it lacks access to the internal workings of a LinkedList).
If it were done this way, the Collections class would be much smaller, and contain mostly methods that return wrapped classes.
After thinking about it a while, I think I can answer this question myself. The List interface would become rather bloated, and would force an implementation of methods that the user may not need.
At any rate, I intend to try to do some sort of clean-up. Exactly how, is something I'm still thinking about. Maybe two versions of List interfaces (one "light", and the other advanced), or maybe making the internal fields package private and generally more accessible to other package members, so that methods in other classes can do some optimizations with the additional information.
2.
At one point, I realized that the PriorityQueue didn't support increase\decrease key operations. Of course, elements would need to know where in the backing data structure it was located, and this is implementation specific. However, I was rather dissapointed that this wasn't supported somehow, so i figured out a way to support this anyway, and implemented it.
Basically, I've wrapped the elements in a class that contains this info, and if the element would want to increase its key, it would call a method on the wrapping class it was contained in. It worked fine.
It may cause some overhead, but at least I don't have to re-implement such a datastructure and fiddle around so much with the element-classes just because I want to try something with a PriorityQueue.
I can do the same thing to implement a reusable BinomialHeap, FibonacciHeap, and other datastructures, that usually require that the elements contain some implementation-specific fields and methods.
And this would all become part of the framework.
3.
This one is difficult ot explain.
It basically revolves around the first question in the "Java Collections API Design FAQ".
It has always bothered me that the Collection interface contained methods, that "maybe" would be implemented.
To me it didn't make sense. The Collection should only contain methods that are general for all Collections, such as the contains method. All methods that request, and manipulate the Collection, belonged in other interfaces.
However, I also realized that the whole smart thing about the current Collection interface, is that you can transfer elements from one Collection to another, without needing to know what type of Collection you were transferring from\to.
But I still felt it violated "something" out there, even if it was in the name of convenience. If this convenience was to be provided, it should be done by making a separate wrapper interface with the purpose of grouping the various Collection types together.
If you don't know what I'm trying to say then you might have to see the interfaces I've made.
And while I as at it, I also fiddled with the various method names.
For example, add( int index, E element), I felt it should be insert( int index, E element). This type of minor things caused a lot of confusion for me back then, so I cared enough about this to change it to somthing I thought more appropriate. But I have no idea how appropriate my approach may seem to others. : )
4.
I see an iterator as something that iterates through a collection, and nothing else.
Therefor, it bothered me that the Iterator interface had an optional remove method.
I myself have never needed it, so maybe I just don't know how to appreciate it. How much is it used? If its heavily used, I guess I'm going to have to include it somehow.
5.
A LinkedList doesnt' support random access. But true random access is when you access randomly relative to the first index.
Iterating from the first to the last with a for statement isn't really random access, but it still causes bad performance in the current LinkedList implementation. One would have to use the ListIterator to achieve this.
But even here, if you want a ListIterator that starts in the middle of the list, you still need to traverse the list to reach that point.
So I've come up with LinkedList that remembers the last accessed element using the basic methods get, set, remove etc, and can use it to access elements relatively from it.
Basically, there is now an special interal "ListIterator" that is used to access elements when the basic methods are used. This gives way for several improvements (although that may depend how you look at it).
It introduces some overhead in the form of if-else statemenets, but otherwise, I'm hoping that it will generally outperform the current LinkedList class (when using lists with a large nr of elements).
6.
I've also played around with the ArrayList class.
I've implemented it in a way, that is something like a random-access Deque. This has made it possible to improvement certain methods, like inserting an element\Collection at some index.
Instead of always shifting subsequent element to the right, elements can be shifted left as well. That means that inserting at index 0 only requires a single operation, instead of k * the length of the list.
Again, this intrduces some overhead with if-else statements, but is still better in many cases (again, the List must be large for this to pay off).
7.
I'm also trying to do a hybrid between an ArrayList and a Linked list, hopefully allowing mostly constant insertion, but constant true random access as well. It requires more than twice the memory, since it is backed by both an ArrayList and a LinkedList.
The overhead introduced , and the fact that worst case random access is no better than that of a pure LinkedList (which occurs when elelements are inserted at the same index many times, and you then try to access these elements), may make this class infeasible.
It was mostly the first three points that pushed my over the edge, and made me throw myself at this project.
You're free to comment as much as you like.
If no real discussion starts, thats ok.
Its not like I'm not having fun with this thing on my own : )
I've started from scratch several times because of design problems discovered too late, so if you request to see some of the source code, it is still in the works and I would have to scurry off and add a lot of java-comments as well, to explain code.
Great. Thanks!

This sort of reply has great value : )
Some of them show me that I need to take some other things into consideration. Some of them however, aren't resolved yet, some because I'm probably misunderstanding some of your arguments.
Here goes:
1.
a)
Are you saying that they're were made static, and therefor were implemented in a utility class? Isn't it the other way around? Suppose that I did put them into the List interface, that would mean they don't need to be static anymore, right?
b)
A bloated List interface is a problem. Many of them will however have a default not-so-alwyas-efficient implementation in a abstract base class.
Many of the list-algorithms dump sequential lists in an array, execute the algorithm, and dump the finished list back into a sequential list.
I believe that there are several of them where one of the "dumps" can be avoided.
And even if other algorithms would effectively just be moved around, it wouldn't neccesarily be in the name of performance (some of them cannot really be done better), but in the name of consistency\convenience.
Regarding convenience, I'm getting the message that some may think it more convenient to have these "extra" methods grouped in a utility class. That can be arranged.
But when it comes to consistency with method names (which conacerns usability as well), I felt it is something else entirely.
For example take the two methods fill and replaceAll in the Collections class. They both set specific elements (or all of them) to some value. So they're both related to the set method, but use method names that are very distinguished. For me it make sense to have a method called setAll(...), and overload it. And since the List interface has a set method, I would very much like to group all these related methods together.
Can you follow my idea?
And well, the Collections class would become smaller. If you ask me, it's rather bloated right now, and supports a huge mixed bag of related and unrelated utitlity methods. If we should take this to the extreme, then The Collections class and the Arrays class should be merged.
No, right? That would be hell : )
2,
At a first glance, your route might do the trick. But there's several things here that aren't right
a)
In order to delete an object, you need to know where it is. The only remove method supported by PriorityQueue actually does a linear search. Increase and decrease operations are supposed to be log(n). Doing a linear search would ruin that.
You need a method something like removeAt( int i), where i would be the index in the backing array (assuming you're using an array). The elemeny itself would need to know that int, meaning that it needs an internal int field, even though this field only is required due to the internal workings of PriorityQueue. Every time you want to insert some element, you need to add a field, that really has nothing to with that element from an object-oriented view.
b)
Even if you had such a remove method, using it to increase\decrease key would use up to twice the operations neccesary.
Increasing a key, for example, only requires you to float the element up the heap. You don't need to remove it first, which would require an additional log(n) operations.
3.
I've read the link before, and I agree with them. But I feel that there are other ways to avoid an insane nr of interfaces. I also think I know why I arrive at other design choices.
The Collection interface as it is now, is smart because it can covers a wide range of collection types with add and remove methods. This is useful because you can exchange elements between collections without knowing the type of the collection.
The drawback is of course that not all collection are, e.g modifiable.
What I think the problem is, is that the Collection interface is trying to be two things at once.
On one side, it wants to be the base interface. But on the other side, it wants to cast a wide net over all the collection types.
So what I've done is make a Collection interface that is infact a true base interface, only supporting methods that all collection types have in common.
Then I have a separate interface that tries to support methods for exchanging elements between collections of unknown type.
There isn't neccesarily any performance benefit (actually, it may even introduces some overhead), but in certainly is easier to grasp, for me at least, since it is more logically grouped.
I know, that I'm basically challenging the design choices of Java programmers that have much more experience than me. Hell, they probably already even have considered and rejected what I'm considering now. In that case, I defend myself by mentioning that it isn't described as a possiblity in the FAQ : )
4.
This point is actually related to point 3., becausue if I want the Collection interface to only support common methods, then I can't have an Iterator with a remove method.
But okay....I need to support it somehow. No way around it .
5. 6. & 7.
The message I'm getting here, is that if I implement these changes to LinkedList and ArrayList, then they aren't really LinkedList and ArrayList anymore.
And finally, why do that, when I'm going to do a class that (hopefully) can simulate both anyway?
I hadn't thought of the names as being the problem.
My line of thought was, that okay, you have this arraylist that performs lousy insertion and removal, and so you avoid it.
But occasionally, you need it (don't ask me how often this type of situation arises. Rarely?), and so you would appreciate it if performed "ok". It would still be linear, but would often perform much better (in extreme cases it would be in constant time).
But these improvements would almost certainly change the way one would use LinkedList and ArrayList, and I guess that requires different names for them.
Great input. That I wouldn't have thought of. Thanks.
There is however some comments I should comment:
"And what happens if something is suibsequently inserted or removed between that element and the one you want?"
Then it would perform just like one would expect from a LinkedList. However if that index were closer to the last indexed position, it would be faster. As it is now, LinkedList only chooses either the first index or the last to start the traversal from.
If you're working with a small number of elements, then this is definitely not worth it.
"It sounds to me like this (the hybrid list) is what you really want and indeed all you really need."
You may be right. I felt that since the hybrid list would use twice as much memory, it would not always be the best choice.
I going to think about that one. Thanks.

SAP data collection framework - owner change

Hi,
in the data collection framework there is an owner assigned to all data collectors. In general the owner is the SID system itself.
If another system (i.e. solman) is connected to the system, the owner of the data collector changes to that system.
The data collection does not work any longer and creates a lot of errors.
I can change back the owner, but it changes immediately to the connected system.
Why does the data collector not work with the "foreign" owner? And why does the owner change at all?
Best regards
Arne

Dear Mr. Knoeller,
Your SAP_BASIS SP and release would be helpful, both for SolMan and the managed system.
Until then, could you please check the following notes and KBAs, in this order:
1927012 - SYB: DBACockpit shows warnings about data collectors not
being properly set up or having a different version
1972114 - SYB: Error in DCF ownership transfer - should solve your issue in my opinion
1712802 - SYB: Change ownership of Data Collection Framework /
ATM
1623182 - SYB: Authorization issues in DBACockpit
In case this is a test system, if the mentioned notes do not offer you a propper resolution, I would also drop all the collectors (Framework Collecter would be the last one, of course) and reassign it to Solution Manager. This also depends on your NW release, SP and DBA Cockpit rellease.
Relevant notes regarding DBA Cockpit version known by me:
1757928 - SYB: DBA Cockpit Release Notes 7.02 SP11, 7.30 SP6, 7.31
SP2
1758182 - SYB: DBA Cockpit Release Notes 7.02 SP12, 7.30 SP8, 7.31
SP5
1758496 - SYB: DBA Cockpit Release Notes 7.02 SP13, 7.30 SP9, 7.31
SP7
1814258 - SYB: DBA Cockpit Release Notes 7.02 SP14, 7.30 SP10, 7.31
SP9, 7.40 SP4
Kind Regards,
Ionut

Use of transient fields in Collections Framework?

Hi all,
I've been playing around with the reflection API for introspecting various members of the Collection Framework (CF).
It turns out that many of the fields used by the members of the CF use the transient fields for their data-storage. For example: ArrayLists stored their elements in a transient field named elementData.
Following the Java Language Specification, the transient fields are therefore not part of the object's persistent state. As a consequence, it is "not" possible to make such an object persistent (although, from what I understood, you could serialize such an object including its element data).
Is there any particular reason why those fields are defined as transient?

Hi all,
I've been playing around with the reflection API for
introspecting various members of the Collection
Framework (CF).
It turns out that many of the fields used by the
members of the CF use the transient fields for
their data-storage. For example: ArrayLists stored
their elements in a transient field named
elementData.
Following the Java Language Specification, the
transient fields are therefore not part of the
object's persistent state. As a consequence, it is
"not" possible to make such an object persistent
(although, from what I understood, you could serialize
such an object including its element data).
Is there any particular reason why those fields are
defined as transient?You need to distinguish between the data logically contained by a Collections object (or indeed any other), and how that data is represented both in memory, and in the persisted form. A class marks a field transient simply to inform the default serialization mechanism that the field does not form part of the persistent representation. Typically this is either because it is only used for cacheing purposes, or because the class itself takes responsibility for the persisted form.
The Collections classes often have a complexity in their memory representation that is related to their performance requirements, but which serves no purpose in their persisted form. Consider a TreeMap, for example. Its memory representation involves a tree, but the only things that need to be persisted are the key/value pairs. Persisting the tree would be wasteful in both time and peristent storage.
Sylvia.

Create new Collection by simply dragging a "Folder" into "Collections"

Ability to create new Collection by simply dragging a "Folder" into "Collections". Currently the collection name has to be created manually and files dragged into it.
Note: Collections are important because this is the only way you can have "virtual copies" separated into different folders. For example I wanted to have set of virtual B&W images in its own folder (and the original color images in a different folder). You could only do this in "Collections". "Folders" does not allow you to separate a virtual copy from its original (because the virt copy is not really a file).
Joe

Thanks Sean, Good analogy! I'll have to give your method a try.
However, I'm finding that in LR1.0 I'll probably need to create a "Collection" of almost all my "Folders" (past and future) because of the ability to have virtual copies separated into sub collections. To do so, even in the way you describe, seems to require too much typing. It would be nice to be able to simply drag folders (which I've already gone to the trouble of naming) into a Collection and have it keep the name. In Beta 4 you only had "Shoots" to deal with, hence it wasn't an issue. Now you have "Folders" and "Collections". That in itself is a little confusing; but I understand why it was done (i.e. the "why no folders?" complaints of beta testers).
Speaking of not liking to type; I've already typed too much here... : )
-Joe

Creating new "Collection Set" deselects everything for no reason.

In Library mode: Creating new Collection Set performs "Select none" (changes source) for no reason. A new set cannot contain photos (until it has a collection) so there is no reason to change source to it yet. It is behaving as if it were a new collection. I often select photos first, then decide whether they need to be in a collection. If I need to first create a set for it --I lose the selection before I can place them.
Is this "as designed" and am I overlooking something?

If Verizon sent you an STB, it should have been delivered via a delivery service (they use UPS around here). Included in the paperwork should have been a return label that would allow you to drop it off at any UPS store, and the return shipping would be free.
If I were you, I would keep whichever STB and remote look to be in better condition, pack up the other one with any accessories they demand to have returned, and drop it off at whichever service delivered it. Make sure to get and keep some kind of confirmation number that the delivery service has received the box. Though I've never had any problems myself, I've heard a few horror stories about Verizon claiming to have never received the returned merchandise and trying to charge the customer for it. Better safe than sorry.
FYI - The reason that FIOS triggers the spell check is because it is spelled FiOS (Fiber Optic Services).
Find this post helpful, informative or just something you agree with? Click the red ‘thumbs-up’ button.
Did this post solve your problem? Click the green ‘Accept as Solution’ button.

Why New Apple TV is New?

Hi All.
I just can't understand why new apple tv is called "new" by apple. Its just size of hard drive is bigger ....or I am missing something?
Regards

I knew about software thing. A software upgrade dosent makes Apple TV new, for me anyway. I guess it won’t be last time when Apple release upgrade software for Apple TV, so they will call again “new” Apple TV. I am just trying to make my point here because usually “new” in Apple terms mean new hardware, interface etc.
Anyway I got first generation (if I can call that a first generation) Apple TV and hopefully upgrade will come soon to us.
Thanks all.

Dont want then NavigationTarget to open an entirely new portal framework

Hi All,
when i tried with Navigationtarget from webdynpro Linktourl element(target=_main) to open the page which has webdynpro iview opening the page but its coming with whole new portal framework which i dont want . how to avoid that.I just want the page to display in the content area without the whole portal framework with tabs and
String URL1="/irj/index.html?NavigationTarget=ROLES://portal_content/org.test.dev.folder.test_development/test/Worksets/CustomApplications/ManagersFMLAApproval";
wdContext.currentContextElement().setUrl1(URL1);
Thanks,
pkv

Hi Pkv,
    If you want to open the new window without the portal framework page then instead of using a LinktoURL UI Element you use a LinktoAction UI element and in the action handler of the LinktoAction you can use the navigateAbsolute portal API. [http://help.sap.com/javadocs/NW04S/current/wd/com/sap/tc/webdynpro/clientserver/navigation/api/WDPortalNavigation.html]
The code should look like this.
WDPortalNavigation.
navigateAbsolute("ROLES://portal_content/org.test.dev.folder.test_development/test/Worksets/CustomApplications/ManagersFMLAApproval",
                 WDPortalNavigationMode.SHOW_EXTERNAL,
                 WDPortalNavigationHistoryMode.NO_HISTORY,
                 null);
Regards,
Sanyev

Having trouble adding new collection in ibooks?

Hi
I am having trouble a adding a new collection in ibooks. When I click on "+New Collection" it disappears and the keyboard does not pop up and then seems to freeze. It was working fine yesterday and only encountered this problem this morning.
Has anyone else had this problem or know how I go about fixing it?
Thank you!

The problem is not thru TWC... I can access my account in Outlook and also by Webmail.
The problem is on the Iphone 4 (I had no problem on my 3G). Like I said, the settings I have entered are the same as the settings for the other 4 accounts. The only portion of the setup that I cannot access during the "failed" setup is the "Advanced" where I can turn SSL off and confirm password authentication.

I created a new collection and put all of my same photos in them as a previous collection, then I changed them to black and white and both collections changed. How do I keep the first collection colour and make the second collection black and white.

I created a new collection and put all of my same photos in them as a previous collection, then I changed them to black and white and both collections changed. How do I keep the first collection colour and make the second collection black and white.

For the second collection, choose the option to make virtual copies. Then you can turn the virtual copies to black & white, leaving the first collection in color. If you want file copies of the B & W images you can export copies.

New Infotype Framework

Hello!
I'm just going to implement a new Infotype that should use the Data Sharing functionality for Concurrent Employment. I've read a document about the implementation of the "new" Infotype Framework, but I haven't found an example how to use it for my needs. Is there an example for the use of the Infotype Framework (e.g. Classes CL_HRPA_DATA_SHARING, CL_HRPA_INFOTYPE_FACTORY, ...).
Has anyone ever used the framework to insert/modify an IT-record?
Thanks in advance!

Hi Juergen,
I know i am too late in replying to your question.
However, better to be late than naver, I thought I will share with you how i achieved it in my last project.
You can refrer to the below example code ( Logic for inserting record in infotype 0015).
Note: Structure wa0015 type PA0015 contains the data which you want to
        update in infotype 0015.
FIELD-SYMBOLS: <ls_pnnnn> TYPE p0015.
ASSIGN p0015 TO <ls_pnnnn> .
create instance
CALL METHOD cl_hrpa_masterdata_bl=>get_instance
    IMPORTING
      masterdata_bl = g_masterdata_bl.
CREATE OBJECT g_message_handler.
MOVE-CORRESPONDING wa0015 TO <ls_pnnnn>.
<ls_pnnnn>-infty = 0015.
start trial
    CLEAR g_magic_cookie.
CALL METHOD g_masterdata_bl->start_trial
    IMPORTING
      magic_cookie = g_magic_cookie.
create infotye container
CLEAR g_is_ok.
CALL METHOD g_masterdata_bl->get_infty_container
    EXPORTING
      tclas           = c_tclas
      pskey           = <ls_pnnnn>-pskey
      message_handler = g_message_handler
    IMPORTING
      container       = g_container.
<ls_pnnnn>-pskey     = g_container->a_pskey.
g_container_nnnn ?= g_container.
g_container      ?= g_container_nnnn->modify_primary_record( <ls_pnnnn> ).
insert record in infotype
DATA: ls_bapiret1 TYPE bapiret1.
CLEAR g_is_ok.
CALL METHOD g_masterdata_bl->insert
    EXPORTING
      message_handler = g_message_handler
    IMPORTING
      is_ok           = g_is_ok
    CHANGING
      container       = g_container.
success
IF g_is_ok = c_true.
CALL METHOD g_masterdata_bl->approve_trial
    EXPORTING
      magic_cookie = g_magic_cookie.
commit work
CALL METHOD g_masterdata_bl->flush
    EXPORTING
      no_commit = space.
error
IF g_is_ok IS INITIAL.
discard trial
CALL METHOD g_masterdata_bl->discard_trial
    EXPORTING
      magic_cookie = g_magic_cookie.
append errors
DATA: lt_msg TYPE hrpad_message_tab,
        ls_msg LIKE LINE OF lt_msg,
        ps_return TYPE bapiret1.
IF g_message_handler->has_abend( ) = 'X'.
    CALL METHOD g_message_handler->get_abend_list
      IMPORTING
        messages = lt_msg.
ELSEIF g_message_handler->has_error( ) = 'X'.
    CALL METHOD g_message_handler->get_error_list
      IMPORTING
        messages = lt_msg.
ELSE.
    EXIT.
ENDIF.
LOOP AT lt_msg INTO ls_msg.
    CALL FUNCTION 'BALW_BAPIRETURN_GET1'
      EXPORTING
        type       = ls_msg-msgty
        cl         = ls_msg-msgid
        number     = ls_msg-msgno
        par1       = ls_msg-msgv1
        par2       = ls_msg-msgv2
        par3       = ls_msg-msgv3
        par4       = ls_msg-msgv4
      IMPORTING
        bapireturn = ps_return.
    APPEND ps_return TO pt_return.
ENDLOOP.
ENDIF.
Regards,
Dinesh Pandey

Default Collection Set For New Collect

Good Morning,
Since upgrading to 5.2 I notice that when I right click on a collection set to create a new collection Lightroom does not default to the collection set I right clicked on as the "Inside Collection Set" if my original collection set is nested inside another collection set. I am then force to scroll through a long list of collection sets to choose the correct one.
It did not work like this in previous versions - 5.0 or 3.6.
Is this an intentional change or some type of bug?
Thanks
Harry

I have the same issue. In previous version of LR you could control click on a collection set, select "create collection" and the window would open with the same collection set selected. Now it jumps to the parent collection set of the one you clicked on forcing you to go back and scroll through to find the original collection set. It's a small issue but a pain all the same.

Why new final cut X is so restrictive connected clips? I do not see benefit.

I am coming from final cut 7 and I have no idea why new final cut X is so restrictive in having primary storyline and connected clips. I loved how in FC7 all clips were independent in timeline and gave you freedom to move and organize your clips however you wanted.
Now I have to take extra steps or jump through hoops to move clips around becaused they are connected to primary storyline. Like I have to create secondary storylines. Really??
I do not see any benefit to connected clips except that it automatically follows primary storyline when you move primary clip around - which most of time I do not want it to do. We should be able to turn this off because I do not see any benefit to connected clips with primary storyline.
FCX is dictating how we organize clips on timeline which is way more restrictive than FC7. This is just wrong.
Also bring back enable tracks. Why in the world did they remove tracks. Tracks work and is easier to visualize and organize clips in timeline. Like if I wanted to disable audio or video for a track it was just one click in FC7. Now there are extra steps in FCX They should enable this for people who are use to tracks.
They should really talk scold to whoever mad scientist who wanted to make FCX more restrictive than FC7 and impose their workflow on everyone else.
I like magnetic timeline where you can move clips around and other clips will automatically move to make room for it. This save time.
So can we disable connected clips and let us enable tracks just like better FC7?

The first Quantel NLE, back in the 80ies, was mimicing the Moviola - showing vertical stripes of 'film'.
So, you could ask "Why have they changed to horizontal?"
On editing film, you wrote with some white wax pen an X onto it, to indicate a dissolve....
So, you could ask "Why have they changed that to drag'n drop grey boxes?"
On recording they hold a clapper into the cam, to 'sign' the time-code.
So, you could ask "Why have they changed that to meta-tags, hidden invisible in the file?"
Aside doing compos ('Brady Bunch', '24'), there are no 'tracks' in no movie.
In any movie, there's always just a single storyline...
If you like to apply 'variations', get customed to FCPX' Auditions.
If you like to adjust cut-aways, get customed to the various trim/ripple/nudge options of FCPX.
If you like to pre-select clips, get customed to the Events-concept and its endless options (you can even abuse to create 'bins'!) to tag clips.
If you like to 'pre-comp', get customed to FCPX' compounds and their own timelines.
It is a different, a new way of editing. That simple.
As others told you: nobody forces you to adopt it.
There's AP, there's DaVinci Resolve .... and many others.
And you even can Position a clip...
Russ H wrote:
@Tom and David: OP has posted identical comment in Creative Cow/The Debate.
excellent obeservation...
Such a debate comes two years too late here, I assume...

Why new collection framework

Similar Messages

Maybe you are looking for