Re: A problem with replicating a subgroup
Le 22 janv. 10 à 00:12, planix a écrit : Hi Andre, The mod that you suggested, setting the topleft of the new to the bottom left of the old worked perfectly. Just the way I want it to. Thanks very much for that. Bonjour Alistair, Your are welcome! This list is like a race: often when I am on the verge of responding to a question, I see that a couple of people has already answered ;-)) Very happy when I win ;-o))) Best regards from Grenoble André ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: A problem with replicating a subgroup
Hi Andre, The mod that you suggested, setting the topleft of the new to the bottom left of the old worked perfectly. Just the way I want it to. Thanks very much for that. Alistair -- View this message in context: http://n4.nabble.com/A-problem-with-replicating-a-subgroup-tp1049682p1068959.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: A problem with replicating a subgroup
Alistair, After some more trials : 1 - I think you are right : clone invisible group "grpPlan1" (and then show it) is better. 2 - In the solution I suggested, the subgroup are more separated (the blank between 2 subgroups is higher). If you find it is too much, you can reduce the margins of the subgroup model (the first one) in the "Text formatting" pane of the Inspector. Best André ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: A problem with replicating a subgroup
Le 21 janv. 10 à 13:28, planix a écrit :
Hi,
The issue I have is a bit complicated to explain so I have uploaded an
example stack ("A Group Replication Problem") to revOnline. You
should find
it if you search for me or look for a stack tagged 'Test'.
Basically, I have a scrolling group set up with a subgroup which I
want to
be able to replicate as many times as I need. Each replication is
managed by
a button ("New Case Plan") which clones the subgroup, changes some
custom
properties, and then places the cloned subgroup a certain distance
beneath
the previous subgroup. I can delete each replication in sequence
back to the
first subgroup which is not deleteable as I use it as the 'template'
for
replication.
This all works fine. I can press the "New Case Plan" button as many
times as
I like and all the replicant subgroups all line up nicely in the
scrolling
group. I can also delete any new replicant as expected. So, what I
am saying
is that the code works as expected. Though I am betting that it is
clumsy-
so any thoughts on how to make the code itself more efficient or
elegant
would be welcomed.
The problem is this. All of the above works fine so long as I don't
scroll
to the bottom of the group, so that the last replication is showing,
before
I press the "New Case Plan" button. If I do that the next
replication is
displaced well away from the previous one and is not the neat and tidy
separation that I expected. If I keep on doing that the distance
between
replication becomes increasingly larger.
Bonjour Alistair,
Try the following modifications to the script of button "New Client
Plan"
-
put the cpCurrentGrpNum of grp "grpCarePlan" into theNumber
--set up to track and record the new subgroup location
put item 1 of the cpCurrentGrpLoc of grp "grpCarePlan" into theLeft
--add a constant displacement to the down item of loc to ensure
the fields do not overlap
put item 2 of the cpCurrentGrpLoc of grp "grpCarePlan" + 57 into
theDown
--make the copy of the orginal subgroup
clone group "grpPlan1" --invisible group "grpPlan1" SEEMS THAT
CLONING INVISIBLE IS NOT NECESSARY
--note that cantDelete is set to true to stop this subgroup from
being deleted by "btnDeletePlan"
--need to change this so that all replicants can be deleted
set the cantDelete of it to false
--set the name and location of the replicant and then show it
HERE ARE THE MODIF I AM SUGGESTING
put "grpPlan" & theNumber into lastName
put "grpPlan" & theNumber + 1 into newName
set the name of it to newName
set the topLeft of grp newName to the bottomLeft of grp lastName
-- THIS IS THE PRINCIPAL MODIFICATION
--set the name of it to "grpPlan" & theNumber +1
--set the loc of it to theLeft, theDown
set the cpCurrentGrpLoc of grp "grpCarePlan" to the loc of it
--show it
--update the property which keeps track of the number of replicants
set the cpCurrentGrpNum of grp "grpCarePlan" to theNumber +1
---
Seems that it solves your problem: the next replication is not
displaced any more)
Best regards from Grenoble
André
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: A problem with replicating a subgroup
Alistair wrote: ... The problem is this. All of the above works fine so long as I don't scroll to the bottom of the group, so that the last replication is showing, before I press the "New Case Plan" button. If I do that the next replication is displaced well away from the previous one and is not the neat and tidy separation that I expected. If I keep on doing that the distance between replication becomes increasingly larger. I wonder if I have simply used a poor approach to the coding of this functionality and whether there is some simple and elegant approach that would also solve this "bad" behaviour. Or, is this a problem with having a scrolling group since the location of objects within this is likely to become a pretty complicated reference once you start to scroll. Your thoughts on this would be most welcome. If you could have a look at the problem in the stack on revOnline I would appreciate it. Unfortunately I've had little luck with anything working well with RevOnline since v4 was released, so I haven't seen your stack. I have three questions which may help diagnosis: 1. Are the lockLocs of the objects within the group set? 2. Are you accounting for the scroll of the containing group in the code that places the objects? 3. Is the total formattedHeight or formattedWidth of the group greater than 32765? -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
A problem with replicating a subgroup
Hi,
The issue I have is a bit complicated to explain so I have uploaded an
example stack ("A Group Replication Problem") to revOnline. You should find
it if you search for me or look for a stack tagged 'Test'.
Basically, I have a scrolling group set up with a subgroup which I want to
be able to replicate as many times as I need. Each replication is managed by
a button ("New Case Plan") which clones the subgroup, changes some custom
properties, and then places the cloned subgroup a certain distance beneath
the previous subgroup. I can delete each replication in sequence back to the
first subgroup which is not deleteable as I use it as the 'template' for
replication.
This all works fine. I can press the "New Case Plan" button as many times as
I like and all the replicant subgroups all line up nicely in the scrolling
group. I can also delete any new replicant as expected. So, what I am saying
is that the code works as expected. Though I am betting that it is clumsy-
so any thoughts on how to make the code itself more efficient or elegant
would be welcomed.
The problem is this. All of the above works fine so long as I don't scroll
to the bottom of the group, so that the last replication is showing, before
I press the "New Case Plan" button. If I do that the next replication is
displaced well away from the previous one and is not the neat and tidy
separation that I expected. If I keep on doing that the distance between
replication becomes increasingly larger.
I wonder if I have simply used a poor approach to the coding of this
functionality and whether there is some simple and elegant approach that
would also solve this "bad" behaviour.
Or, is this a problem with having a scrolling group since the location of
objects within this is likely to become a pretty complicated reference once
you start to scroll.
Your thoughts on this would be most welcome. If you could have a look at the
problem in the stack on revOnline I would appreciate it.
All the best.
Alistair Campbell
--
View this message in context:
http://n4.nabble.com/A-problem-with-replicating-a-subgroup-tp1049682p1049682.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
