InfoQube IM - Community

Submitted by jsolka on 2009/03/11 09:52

I know I asked that question before, but still can't work it the way I'd like to.

This is the problem: I want to copy item in the same grid (with all formats, subitems, etc) in some simple way. I want this copied item to go just below the item that was copied (the original item). Sometimes I need to do it several times -- that's the easiest way for me to work my Proposals grid, because then i can just change only very little , like one cell and I have it all nice and running.

Jay

Comments

Please try:

Select the main item (click on the # cell)
Edit > Copy
Select Selected items and all sub-items, XML format
Edit > Paste
Refresh (F5)

This will work as long as the main item "belongs" to the grid. It this is not the case (i.e. it is a child of an item that belongs to the grid), You'll need these additional steps

Find the new item (Journal, Edit>Find, etc)
Make it a child of the same parent as the original item (drag-drop or tag it and add tag items as sub-items)

Given my ignorance, this is dangerous

but wouldn't <CTRL>+Drag/Drop work for him ?

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-1

No. Ctrl-drag-drop simply creates a link to a new parent.

jsolka want a true copy (new set of items)

Tried it -works beautifully. But Pierre is unfortunately right - it is not a new item so I can't change anything because the original item would change, too.

Thanks,

Jay

1. I didn't quite understand the second part.

2. But when I checked the filed "proposals" in the properties pane, it worked.

3. However there is another problem -- the item goes to the very bottom not just below copied item.

4. Would it work if all the items & suditmes had "proposals" field in properties pane.

5. Is there any reason that i shouldn't do it?

6. Can I do it automatically?

Thanks

Jay

I'd need a picture of you grid + sourcebar + toolbar to help you more

If you still have my proposals file you could try it. Try to copy one of the items (it's 4th level in this case, when the GC, PROJECT, Date, Prop# fields, etc appear) and make it go just below the original (copied) item. Thanks.

Jay

P.S. I found a better way to solve my problem -- inheritance feature in manage fields for subitems. But I guess it is only a limited solution.

Have a great day Pierre

Be careful with inheritance... This could have other unwanted effects (like items appearing in places you don't want them, because of 2 bugs related to hierarchy display). I'd personally stick with Pierre's recommendation in post #2 for copying items. (When you want to create multiple parents for items, ctrl drag and drop is the way to go (but this is NOT copying)).

It sounds scary. I tried it in my grid, and when I added a sub item to the main item (I need this for different clients with the same main proposal/project) the sub items had the same values in the fields that i set up the inheritance for. But I guess, if there are bugs, I need to really test it thoroughly first (time, time!). And I still would like to be able to just copy the item in a simple way and the this item would go just below (I seem to need it very often indeed). Pierre responded to me, and hopefully he may find a solution for me.

Thanks

Jay

The bugs are not that scary and are only related to hierarchy display in certain circumstances -- they can be ennoying though. Check mantis issues 213 and 214 for description.

As for the simple copying/pasting, I agree that it should be much much simpler... And should always work as expected (XML is pretty full proof -- apart from the problem of items not appearing in the grid when not meeting the source + not appearing where the "focus" is -- but the TAB separated one is a tad shaky : had problems this morning using it to copy several items in a grid, and... no idea whatsoever what the problem was, really. I had refreshed, before, etc. No idea... Will explore more. But....)

[quote]

Armando wrote:

apart from the problem of items not appearing in the grid when not meeting the source"

I know of one way to make the item to "meet the source" and this is by ticking the pertinent box in the property pane's "available fields". [/quote]

Two questions:

1. Is there any contraindication against making all items meet the source? (In other words what could be the case the I don't want some/all items to "meet the source")

2. How can I set up the grid that all its items automatically will "meet the source".

Thanks,

Jay

> 1. Is there any contraindication against making all items meet the source? (In other words what could be the case the I don't want some/all items to "meet the source")

Apart from the two bugs mentioned above, not really. BUT, depending on the grid's usage, it might become difficult to differentiate what really is an item of a certain type and what's not...

E.g. : in a ' Contact ' grid, you might want to have some contacts and other stuff (comments, notes about certain projects, etc.). And what if you want to show only the contacts without anything else ? How will you filter these 'out' ?

So one thing you might want to ask yourself every time you use inheritance : what does it mean in that particular case. Or, in other words, what does the inheritance of a field used as a source mean in the context of a specific grid ?

>2. How can I set up the grid that all its items automatically will "meet the source".

Just set the source field's inheritance to "on". That's it.

(If you have already created items in a grid, but some don't meet the source because of the past "no inheritance" configuration, just expand all levels, select all items and apply the Yes/No (or whatever) field to all.)

Now, here's how I manage most of my source (not all of them though... It depends on the meaning of a particular grid : for some grid, this "complexity" is not necessary -- in my db, the "inbox" grid, for instance, remains with a "single field" simple source)

(I think I've explained this somewhere else... But can't find it... So here it is again...)

1- Most of my grids have a source based on this double-field format : ["no inheritance" field] OR [field with inheritance]

E.g. : Contact OR AddressBook

Some details about these 2 "source fields" :

["no inheritance" field] (which we could call the "item's nature" field) :

- Usage : determines the "true" nature of an item (if it's a contact, an event, whatever -- of course, it can be multiple things. But the user gets to choose... IQ being IQ...)

- Special config. : It's a yes/no field with no other specification.

[field with inheritance] ( which we could call the "grid marker" field) :

- Usage : serves as marker to determine if an item is displayed in a grid
- special config. : it's a yes/no field with inheritance ON + delete on item move (the field is really ONLY a marker to identify what's displayed in a grid.)

2- The order of the fields in the source is important.

...Why ? because the first field in the expression will automatically be assigned to ALL items entered in the grid, but only if they're top level items. Other items, if entered directly as subitems, will have to be manually assigned the field. This is how IQ functions, automatically, by design at the moment.

3- In the "Grid auto-assign" entry box (in the manage grids window) one has to add the field with inheritance (which I called the "grid marker" field) so that any item added to that grid will *always* be marked as being displayed in this grid. Any sub-item placed under an item with that field will also be assigned that field (inheritance)

What are the advantages of such a method at the moment ?

Looking for an item (through the various filters) is much, much much more easy. Why ? well, try this : in one of your grid that has a single field as a source (with no inheritance), try to find and isolate an item that doesn't meet the source. Good luck... It's possible, but not very intuitive.

Otherwise, keeping the address book example above, just type in the filter box :

textfields like "*write whatever you want*"

or even

item like "*write whatever you want*"

etc,

and here you go... you'll see all occurences (in a specific grid) meeting these criteria, without having to remove/change the source or whatever

And If you want to see only the items that pertain to the nature of what should be in the grid, without all the notes and fluff (ie. : address book --> want to see only the contacts), just write "contact" in the filter bar. That's it. Here you go : only the contacts.

To try this technique easily, you can just create a new field for each grid (what I did is prefix all these new fields with some specific characters -- "zz" in my case -- so that they're clearly identified as "grid marker" fields). Don't forget to set inheritance on for these. And don't forget to : 1- put them in the right order in the source bar! 2- add the field with inheritance in the auto-assign box of the grid management window.

The only problem with this method at the moment is that items entered through the "add item" window, will not get the same treatment as if they were entered/moved directly in a grid. Which means that if you want an item to be displayed in a specific grid, using the "add item" window, you really have to choose through which way : as an item that is just displayed in a specific context, or as an item which "true nature" corresponds to the main theme of a specific grid. It's not necessarily a flaw... it just makes things a bit more complex. generally speaking, it doesn't prevent the system to work.

A work around, is to have an auto-assignment rule for the field with no inheritance.

e.g. : my contact field has the

A: addressbook = 1

rule to make sure that any contact is always part of the Address book bigger "whole". I don't have any "E:" rule as it is not really necessary in that case, but it could be in other situation (where one could write : E: addressbook = just to make sure that the field is emptied when an item is not a contact anymore...)

i hope that was clear... It was somewhat hard to explain... :)

Armando -

any chance you could create a page (like the one you did for drag n drop) about this ?

would be very helpful I think (actually on a quick look I didnt see any page specifically about copying items)

Thanks, Armando!

The first part answered my question enough for now, but to really understand the rest (I think very important) I would need to have some more time, which is quite possible I might before I retire. Thanks so much.

One thing -- I maybe misunderstood something. When I checked the value box under "inheritance" in
manage fields" and than created a sub-item, and then checked in the property pane for that new sub-item whether the field "proposals" which determines the source grid for the grid "Proposals", the box wasn't checked, which means that the new sub-item didn't "belong " to the grid "Proposals".

Jay

Not sure what's happening...

If a field's inheritance is "on" (checked), then any subitems of a particular item that has that field filled with some data should have/share the same data. If that's not what's happening, you might be doing something weird somewhere.

e.g.

Let's say the yes/No field "test" has inheritance checked. If "item 1" has "test" checked (Yes), then all sub items should have the "test" field checked (yes). Unless the user changes manually the value of one of the sub-items.

Does it mean that if I check in the property pane all the fields for the new subitem the exactly same fields should be checked in the property pane that were checked in the original(parent) item?

That's not what's happening in my grid.

Thanks

Jay

>the exactly same fields should be checked in the property pane that were checked in the original(parent) item?

Well... Not all the fields. Only those for which you have the inheritance turned on (that's done in the field properties window).

Inheritance is not hard to understand. It just means that the characteristics of an item will be transferred to its sub items,on a per field basis, depending on which field has inheritance turned on or off.

Describe all the steps to us, from when you turn inheritance ON to the creation of an item, a subitem, etc.

Thanks. You right, now i understand it perfectly.

(However, there is another question -- how to set up a particular grid , so that every added item, be it a subitem a sibling, etc. will "belong" (have the same grid source) to the grid?

BTW -- what is the easiest way to add a parent to exiting items?)

Never mind, I've set up inheritance to the grid field and it works, with all kinds of added items -- they all belong to the grid. Not only subitems. On the other hand that works but it's not what the form says -- only subitems should inherit the (in this case "yes" ticked) value. Is that a bug?

Jay

> On the other hand that works but it's not what the form says -- only subitems should inherit the (in this case "yes" ticked) value. Is that a bug?

What do you mean ? I'm not sure I undestand. What seems a bug to you ?

I'm just saying that if you go: Manage Fields->inheritance, you will see Value->Subitems, which I understand that only subitems would inherit that the yes/no field will have either checked box or not, but here any item would inherit this characteristic (meaning will belong to this "grid-item"). This serves my purposes but it doesn't seem to do what I read it will. But maybe the checkmark is not really "value" because if this check box weren't checked it wouldn't be; there at all? Or maybe I'm not understanding something here? Am I complicating things?

Jay

Like I said, inheritance only means that an item will share its parents' data (for the fields with inheritance on).

But don't forget that an item can be displayed on its own or have multiple parents, which means that even if an item is displayed differently (i.e. : Under a different parent, on its own... Because of the use of various filters) it will keep the data inherited from the other parent -- it would be weird if it would loose data because it's displayed differently, no ? It's fairly straightforward.

Also : when you establish a simple source for a grid, any top level item will have a value for that field. That's how IQ works, so that items created in the context of a certain grid are associated in some way to that grid.

There's another option (just below the value-> subitem option) that can be handy in certain situation where you don't want a subitem to keep a value if its affiliation with a certain parent is removed : "can delete on item move". I use that a lot, for the grid "source field" (see my long post above).

Does that make it clearer? Honestly, I don't really understand what's so complicated about inheritance... You seem to make it more complex than it is.

Sorry for wasting your time,but you really didn't understand (I would take the blame for not being too clear). I was just saying that the info in the manage fields seems incorrect. Inheritance IS easy. That wasn't the problem (not after your initial response)! And the incorrect info, even if I'm right, would be a very insignificant, at least in comparison to so many others, an issue. Anyway, thanks -- you are really taking your time to respond for which I am very grateful.

Take care.

Jay

Ok then. No problem.

And you're very welcome.