Absolute X

[Giraldo Allain]

Forthe past few weeks my team and I have been noticing this issue where we apply auto layout to a set of items and one of the items will randomly take absolute position property by default. Then you have to go digging around in your layer panel to find which item took the absolute position and turn it off in order for the auto layout to order things as expected (the way it was working previously). Anyone else experiencing this or know how to fix it?

Thank you for your post! When you apply Auto Layout to a frame that already contains elements, we might need to use absolute positioning to maintain your original layout. This approach was introduced last year. There is another thread here: -layout-makes-contents-absolutely-positioned/52495/6.

@y_toku I also faced this problem and seeing that this is intentional behavior is disappointing, to be honest. Instead of quickly hitting Shift+A and adding AL, I need additionally go inside and remove the absolute position. If I make ex. a table with AL it becomes tedious unnecessary work that Figma added on top

And what is even more infuriating is that I cant override what Figma has overridden. I cant remove absolute position to a layer in a component instance that Figma has randomly decided to make absolute.

As a designer managing systems for multiple design teams at an enterprise company, these small changes like applying absolute positioning when an AL property is applied or changed is costing us literal thousands of dollars in lost efficiency.

Hi @Nate_G, Im late to the party I know! but if you use auto complete and then use the component in an auto complete layout, lets say a form, when expanded the dropdown appearing moves the other elements down. That make sense? Not sure what the best way around this is? thanks

@Kevin_Mitchell I used the Auto-layout dropdown example from my previously shared figma file in the above video demo. But I could have also used the absolute position dropdown example in from that file, the concept is the same.

The options to enable absolute accuracy have been removed in 7.0. Default for new models in 7.0 is absolute accuracy (using a start part uses the defined accuracy in the start part). Not sure why you are not being allowed to change from relative to absolute. I am able to change accuracy of old parts. Though most of the time complex parts tend to fail when changing to absolute.

I am very interested as to the issues you have experienced, as so far I have only from other users that absolute accuracy is very stable in Creo7 and causes less failures. What you are saying though is truely a show stopper and may put a stop to us switching to Abs accuracy for any parts at our company. Can you elaborate on how your models are failing when going from Relative to Absolute Accuracy?

The issues I have seen are only with converting models to absolute accuracy and using inheritance features. You do not need to convert old models to start using absolute accuracy. Both relative and absolute models will live happily together in an assembly.

Absolute accuracy works very well when a part is started with absolute accuracy. I work with a lot of contoured surfaces (for seat cushions) and complex shapes (for stamped sheetmetal and plastics). Models tend to lose references and features fail to complete features when converting. We just do not convert old models to absolute accuracy.

We are working in metric and currently use and accuracy of 0.001 mm. I have not experienced any issues that I can attribute to absolute accuracy in creating new models except when using inheritance features.

When creating a new model and trying to inherit a model made with relative accuracy, it will not work. I always have to change the new model to relative to get an inheritance to work when the inherited model is relative.

Our start models have all been converted to absolute and our old models are not being converted. There have been no issues with using both relative and absolute other than using inheritance features. Our mold maker is much happier with the absolute models because he usually remodeled our parts to get the model quality he wanted.

I have never encountered a version dependent issue with accuracy conversion in Pro/E or Creo Parametric. I doubt any of the issues you are describing are release dependent. Converting from relative to absolute has always been fraught with failures. I have had to correct this deficiency in existing designs and often it is faster for me to rebuild the model than to attempt the conversion to absolute accuracy.

If you are working on structural steel parts that have tolerances of +/- 0.1" don't set the absolute accuracy to 1 nanometer. In general I have found that setting the accuracy one order of magnitude smaller than process resolution works well.

As shown by @kdirth Creo 7 still supports relative accuracy. The config option enable_assolute_accuracy is not valid in Creo 7+. Creo 7+ uses absolute accuracy by default. If you have legacy models or start parts that use relative accuracy they are still supported.

I am very curious why Survey123 doesn't seem to support the standard absolute value function! I read Ismael's reply here (Solved: Re: Does Survey123 support the absolute value func... - Esri Community) regarding the issue, and reviewed the 4-step method he proposed for achieving the result. It seems to me that the inclusion of a simple abs() function to return a positive value from a calculation is a no-brainer and would save those of us with the need a lot of extra computational steps.

I am attempting to calculate the amount of twist and out-of-plumbness of telecom towers from field observations. These calculations involve taking the natural log of computed values, which may be symbolically represented as negative values to account for the conditions under which certain observations are made. This means that there will doubtless be times when my observed values in the form mathematically compute to a negative number, though any human engineer analyzing my data would doubtless understand that there really aren't negative values in this context, but rather clockwise/counterclockwise twist directions and off-plumbness directions from the nadir, all of which can be logically understood as positive vectors.

I would love to be able to program such equations into Survey123 to dramatically lighten the post-fieldwork processing of this data, without having to jump through weird programming hoops. I doubt I am the only one wanting something like this!

Hey @AntoinevanEsch!

I was experimenting with that exact if statement yesterday. I thought that would work for sure, but I am still unable to return a calculation. It is definitely possible that there is something else going on with my logic that is causing this, but I am unsure what that might be

A key reason to allow absolute path names is to facilitate a use mode involving many projects accessing the same data. In turn, this may be motivated by preferring to have a very large and relatively stable geospatial data system that is independent of the projects that are using it (and/or independent of the users that are using it; and/or independent of the software that is using it). It may also be motivated by needing to work on so many (100-1000) projects that even a small amount of common data between projects would lead to large amounts of wasted storage space duplicating the same data.

Not everyone works this way. But enough of us do that it should be an option. I teach Arc to college students; I use it in research; I've probably created 300 MXDs in my preferred use mode, which relies on absolute path names.

None of the existing workaround are wholly satisfactory. Using "Save As" and moving folder references from within Pro is cumbersome and only solves half the problem. Using separate drives for data and projects is too restrictive. Scripts to convert relative to absolute paths would be cumbersome.

The simple answer here is that newer, supposedly improved software applications to which we are being encouraged (read: forced) to migrate should be as or MORE functional than the older platforms they purport to replace.

@PatIampietro Totally agree with you. If I had functionality in ArcMap that I can not emulate in Arc Pro without effecting major changes, it is difficult to call this progress. As far as you know, have there been any updates on this subject?

Another instructor here with the same issue. When teaching a new concept, sometimes it is helpful to build off of previous assignments, so students can use a nice map to show the differences between multiple projections, for example. I also ask students to keep their data organized, to prepare them for Real World GIS (which tends to breed chaos between data and maps and all the things everywhere... I digress..)

In this case, I asked them to perform a Save As on the Project (from Lab 5), then store the new APRX in the LABS folder as "Lab6.aprx". The previous project was in the LABS/Lab5 folder, but when they APRX is saved in LABS, the Paths to the Layers, Table, Folder Connections, etc. are all BROKEN. [In hindsight, this is a Teachable Moment, so maybe I shouldn't complain!]

Here's another scenario: I'm asking the Graduate Assistant who has "GIS Experience" to perform some analysis or map some of my research data. I sure as heck don't want them EDITING the data or changing my previous project work, but I don't have Fancy Enterprise cause my Grant was small. So, I Save a Copy of the APRX into a folder they can Edit, but I want to keep the Project Data in a separate folder they can read, but not edit. When I send them a link to their folder, and they open the APRX, it should still point to my GDB, even using Relative Paths, but shouldn't show them Broken Layers. Instead, I have to fix all the layers before sending them the link.

We have a toolbox with ModelBuilder models that is saved in a shared network folder, but gets copied into individual project folders to update some inputs for each project site. Some of the data used in the models is stored in a shared network folder, and I would like the models to be able to maintain the link to that location. Unfortunately, with the default set to maintain relative path names, it always adds the file path of the new project in front of the saved file path to the shared data - breaking the link. If we had an option to switch to absolute path names this wouldn't be an issue. @KoryKramer

3a8082e126