cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X

Mathcad Prime 8: Expand/Collapse area

OJ_10231311
4-Participant

Mathcad Prime 8: Expand/Collapse area

I am a new user of Mathcad Prime 8 and have created a collapsible area for constants/units etc. However I realise that while I expand the area, the content below the area is shifted downward, when I collapse it, it remains permanently shifted, creating an empty space the same size as the height of the collapsed area. So I have to manually remove the empty space. I am missing something or is this a bug? I do remember Mathcad 15 didn't have this issue?

1 ACCEPTED SOLUTION

Accepted Solutions

I opened your file with Prime 6 and can confirm the effect you described, too.

I would call it a bug which could/should be reported to PTC support.

But I wonder how this situation could have been created.  In Prime 6 I was neither able to move a text region as close to an area, nor would Prime allow me to move the area that close to a text region!?

I also tried to create a text region right above the area and then added extra lines in the text region. Doing so I succeeded in creating a text region which overlaps the area, but the buggy effect with the regions below not shifting back could not be seen that way.

 

So I could see the described effect in the file you posted, but I could not replicate it by creating regions from scratch.

 

View solution in original post

8 REPLIES 8

I just tried with Prime 6 and could not duplicate this bug (and it sure is not the desired and intended behaviour that a large empty space below a collapsed area remains after collapsing it).

So its either a bug which was introduced after Prime 6 or (more likely, I guess)  its a buggy installation on your side.

Maybe you could attach a small  demo worksheet which shows  the effect on your side. If others with Prime 8 don't experience this annoyance then you may try to reinstall Prime from scratch and if this does not help you should open a case at PTC support.

 

OJ_10231311
4-Participant
(To:Werner_E)

I have attached the file (in Prime 8 so if someone with Prime  8 can check it, it would be great). I think if there is a text region very close to the collapsible area, then you see this behaviour. In the attached file, you would see that this behaviour is seen in Heading 1, however not with Heading 2. 

Hi,

The effect happens with this file on my machine too.  Prime 8

Cheers

Terry

I opened your file with Prime 6 and can confirm the effect you described, too.

I would call it a bug which could/should be reported to PTC support.

But I wonder how this situation could have been created.  In Prime 6 I was neither able to move a text region as close to an area, nor would Prime allow me to move the area that close to a text region!?

I also tried to create a text region right above the area and then added extra lines in the text region. Doing so I succeeded in creating a text region which overlaps the area, but the buggy effect with the regions below not shifting back could not be seen that way.

 

So I could see the described effect in the file you posted, but I could not replicate it by creating regions from scratch.

 

I see the same issue, BUT, when I move the text region "Heading 1" a bit further above the collapsible area, it will not continue to add empty space. It seems like it's behavior based on whether or not a text region overlaps an expandable area.

 

Hope this helps!

Hi Chris, yes that's what I wanted to imply - any text region too close to the expandable area would trigger this issue and hence it should be farther from the expandable area (as in "Heading 2").

Correct - and your example does demonstrate this. Using "Separate Regions" does solve this issue...but it places your example of "Heading 1" below the first expanding area. Good observation to share - thanks for the heads-up!

I can reproduce the problem and we have similar issue logged in our backlog.

I found additional workaround: use text blocks instead of text boxes to avoid this undesired effect. 

Top Tags