1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

File marked as unsaved incorrectly

Discussion in 'General Discussion' started by JST, Apr 1, 2021.

  1. JST

    JST Alibre Super User

    I have files that do not ask for a save if just opened and closed. But they DO ask for a save if I zoom the view, or change the view angle, but do NOTHING else.

    I have other files (often drawings) which ask for a save every single time they are opened, despite NO editing being done to any part or assembly that is a component of them. If they ARE saved, they will again ask for a save the next time they are opened, even if saved, closed, and re-opened.

    You mentioned that the program will demand to save a file done in an earlier version if it is opened and nothing is done to it. Apparently that is "intended behavior".

    These things appear to be completely unacceptable behavior for professional use.

    The thread you closed was, unfortunately, directly correct and right on the mark as far as unwanted save activity. I know that you do not want to hear that, and may even be angered by bringing it up. But it must be done.

    This really is basic to file integrity. One MUST be able to know when a file has or has not been changed in some way as to the geometry. Now, it is a question, one that cannot be answered. Too many things which do not affect actual geometry will apparently trigger a save.

    We used Pro-E at a prior employer, and that program NEVER did such a thing, even after updates.

    I have used Solidworks, and THAT program never did these things.

    Actually ALIBRE used to never do these things. It is something that has appeared more recently. Unfortunately, I do not have an exact date of the change, but to the best of my recollection, it was somewhere in the time just before or just after the "lost years" of 3DSystems.

    If the program did not do that before, then it should be able to not do them now.
     
    Last edited: Apr 1, 2021
  2. JST

    JST Alibre Super User

    I spoke too soon......

    One file has demanded to be saved 4 times in a row, now. Each of the prior times, I DID save it and close it. And then I immediately re-opened it, only to find it asking for a save AGAIN. AT NO TIME IN THIS PROCESS WAS IT EDITED, OR EVEN ZOOMED, ETC. The "save" menu entry was active as soon as the rendering process was finished.

    It is currently open, and looking at the file menu, "SAVE" is not grayed-out, so if I close it again, it will demand yet ANOTHER save.

    I do not think "save" should be active unless and until an actual edit has been done. And, if the file IS saved and closed, that should save everything clearing all indications of editing, and the file should not demand to be saved unless legitimately edited.

    This is a file which I use for a test, as it is a fairly large file, and has been in existence, and modified, under at least three different versions of the program. It was recently modified again, a few days ago. And saved.

    At that time, it did NOT demand a save every time it was opened, but DID demand it if the view was changed.

    It is large enough that I have not gone through every part and sub to see if any show an error anywhere. BUT, I do not regard an error somewhere buried in the file as a good reason to demand a save every time. And that would not explain the change in behavior, as the recent changes do not show errors. Most of the recent changes were simply moving existing parts around (it is a facility layout).
     
    Last edited: Apr 1, 2021
  3. JST

    JST Alibre Super User

  4. Max

    Max Administrator Staff Member

    JST, this is not what I said. In any case, if you are seeing a file repeatedly asking you to save it over and over in the same session, this is an issue unrelated to the other thread. This is not an issue that we have seen before.

    This is something you need to contact support for and it would be helpful if you can show them a video or screenshare so they can see what you are seeing.

    Thanks!
     
  5. GIOV

    GIOV Alibre Super User

    Max, my humble opinion.
    It would be great if the dependability of a file to the latest version of AD is only to the implementation of a new feature, so the save would be free to be opened by an older version that enjoys the same feature. The user will know in advance what and what not to modify in a model to be reopened by an older version. It would be very good to have an advance warning to avoid, if it is the case, to make a modification not allowed for an older version just when save it. Ideal.
    Would it be too much to ask?
    Glad that you are studying JST issue.
    Thanks and keep safe.
     
  6. Max

    Max Administrator Staff Member

    Just to be clear, this is unrelated to Alibre version (eg version 21, 22, 23). This arises when the user saves a file and its internal file version, something you can't see, gets incremented. That is normal and necessary , but some things can cause incrementing during a save action that may not be obvious.

    The fix would be to keep the behavior of today , but put some logic in that says "if only x, y, or z happen, save without incrementing the version".

    But that is not the issue JST is seeing, I'm almost positive. No one else is reporting that a file must be repeatedly saved over and over, so that's why I suggest the support route so we can see this potentially unique issue in person.

    Thanks!
     
    GIOV likes this.
  7. simonb65

    simonb65 Alibre Super User

    Regarding 'the other thread', I would have posted this on there had it not been closed. Files have been submitted to support. The assembly that is marked 'dirty' and prompts for a save (with no user interaction) was created by AD 2017.1.2) ... if that has any bearing on the issue. Maybe someone else can open one of their older assemblies from the same version and confirm (or not) that they see the same behaviour.
    I really think what @JST is seeing is a similar issue. Just like to add on record, that none of my comments are intended to be derogatory. From my 36+ years of experience you do get to see behavioural patterns in software behaviour that is 'generally' caused by x or y, that's called 'experience' ... A good mantra that's always served me well is "don't assume and don't rule anything out until you've actually ruled it out!".

    I thought that some level of self investigation and logically narrowing down the issue may have been more helpful than a response of "It just crashes" or "Oh yeah, I get that all the time but I just close and start the application and I'm good to go again!". Both of which I trust you'll agree are not helpful, and have been seen on this forum many times, and generally do not help anyone, I know it certainly wouldn't help me or it would draw looking for the issue out so long it just gets pushed down the priority list "until you get more information!". As a former chief engineer once told me ... "Don't just bring me problems, bring me solutions", so, no apologies, but I like to put forward solutions.

    If you don't appreciate the time trying to help, just say (I think you already have, although I wish you would politely not focus on the delivery method, but on the constructive technical content of the message), I'll gladly ignore any glaring issues and move on. I would add that if your issue reporting pages were as easy to add/edit information (images, etc) then I would choose to use that if you don't want things discussing and sharing common issues publicly, which is also intended to discover if it's just me or someone else having the same/similar issue but doesn't think it is an issue (a typical "I just restarted and it went away" user response) ... which ironically is what a forum is for! Maybe you could setup a non-public forum area just for power users that can voice opinion without offending anyone. Just a suggestion.

    All the best intentions ...

    Kind Regards, Simon.
     
    Last edited: Apr 2, 2021
    GIOV likes this.
  8. oldfox

    oldfox Alibre Super User

    My test procedure:

    1. Open assembly from "Open" dialog, not "Recent Files".
    "Save" is greyed out.
    Constraint "Coincident<7>> is broken (Red)
    That is another issue to be addressed at a later time.

    2. Click "X" to close file.
    File closes without asking to save.

    3. Open assembly from "Open" dialog, not "Recent Files".
    Same conditions as step #1.

    4. Grab "P-01-154 - 6535508 Actuator<1>" with mouse and move it.
    "Save" icon goes active (requesting save)

    5. Click "X" to close file.
    "Save Changes?" dialog opens
    I respond "NO"
    File closes.

    6. Open assembly from "Open" dialog, not "Recent Files".
    Same conditions as step #1.

    7. Grab "P-01-154 - 6535508 Actuator<1>" with mouse and move it.
    "Save" icon goes active (requesting save)

    8. Click "X" to close file.
    "Save Changes?" dialog opens
    I respond "YES"
    File closes, apparently with a save.

    9. Open assembly from "Open" dialog, not "Recent Files".
    Same conditions as step #1.
    "Suppress "Coincident<7>"
    Click "X" to close file.
    "Save Changes?" dialog opens
    I respond "YES"
    File closes, apparently with a save.

    10. Open assembly from "Open" dialog, not "Recent Files".
    Same conditions as step #1, plus Coincident<7> is Suppressed

    11. Use "Rotate" tool to change veiwpoint.
    Assembly moves as desired. NO OTHER CHANGES.
    Click "Select" to release "Rotate" focus. No other changes
    Click "X" to close file.
    File closes WITHOUT further requests.

    12. Open assembly from "Open" dialog, not "Recent Files".
    Same conditions as step #1, plus Coincident<7> is Suppressed.

    13. Use "Rotate" tool to change veiwpoint.
    Grab "P-01-154 - 6535508 Actuator<1>" with mouse and ROTATE it.
    Assembly moves as desired. NO OTHER CHANGES.
    "Save" is greyed out.
    Click "X" to close file.
    File closes WITHOUT further requests.

    14. Open assembly from "Open" dialog, not "Recent Files".
    Same conditions as step #1, plus Coincident<7> is Suppressed.
    Click on "P-01-154 - 6535508 Actuator<1>" with mouse.
    Actuator highlights as being selected. No other changes.
    Click "X" to close file.
    File closes WITHOUT further requests.

    15. Open assembly from "Open" dialog, not "Recent Files".
    Same conditions as step #1, plus Coincident<7> is Suppressed.
    Grab "P-01-154 - 6535508 Actuator<1>" with mouse and MOVE it,
    and return to original position.
    Actuator and constrained parts move accordingly.
    "Save" goes active, requesting a save.
    Click "X" to close file.
    "Save Changes?" dialog opens
    I respond "YES"
    File closes, apparently with a save.

    The preceding are just my observations and seem to be correct operations. I understand why each action produces
    it's own results. Apparently no issues.

    I am running platform as in my signature.

    Note:
    Rotating/moving the viewpoint and moving a part are definitely 2 separate things with different results.
    "Zoom in", "Zoom out" or changing view angle do NOT result in requesting "Save" on my system.
     

    Attached Files:

    GIOV likes this.
  9. JST

    JST Alibre Super User

    Ticket submitted.

    Unfortunately, I am not hopeful. So often a minor error several levels down in the assembly is pounced on and blamed for the problem.

    I think that is incorrect, even if it truly IS the issue. Such an error should be simply pointed out by the error handler, even if that is merely "please check subassembly "XYZ".

    It really should not be the case that the existence of an error "somewhere" must be deduced from the existence of a problem, and then discovered by a laborious hours-long process of searching. Surely the software can associate a problem with certain actions or processing a particular part/subassembly.

    Better yet, the parts should be able to be searched by some sort of a "check facility" in the program. Models become so large and complex that manual searching becomes extremely difficult, approaching the time needed to make the model.

    The means presently provided to check, are not really up to the task. In fact, checking in general is inadequate. I found a problem in a file just now, when I did a "regenerate".

    That red constraint DID NOT appear when the file was simply opened, it needed to be regenerated to see the problem. Why is that? Evidently the checks were NOT done on opening, but WERE done on a "regen". Is that sensible? I know it is desirable to have a fast open, but perhaps not at the expense of skipping checks.

    That WAS a file that demands repeated saving, but that does not appear to have been the cause of the save issue......

    Actually, that has come up several times, usually in relation to drawings, but not always.
     
    Last edited: Apr 2, 2021
    GIOV likes this.
  10. Max

    Max Administrator Staff Member

    I wouldn't lose hope just yet. We can reproduce the issue from your file, and that is 95% of the battle. Thank you for your submission. And yes, this is very weird. I do not believe this issue is consistent with what some of the other issues are, but we'll see shortly.
     
    Last edited: Apr 2, 2021
    GIOV and JST like this.
  11. Max

    Max Administrator Staff Member

    Also I updated the title of this thread. The behavior is not related to rotate / zoom / pan / etc. as originally indicated.
     
  12. JST

    JST Alibre Super User

    Well, that file originally had the title behavior, no save request unless zoomed etc. I have no idea if it still will do that, because the other behavior obviously over-rode that.

    However, I would recommend looking at that as well, since it actually DID do as the title said.
     
  13. Drutort

    Drutort Senior Member

    I was wondering if something that could be done to keep things as they are and at the same time, give others more options and control of what is being saved.

    In one of my other software (SprutCAM) their are settings that are given to the user as seen below. What I would like is similar idea that is set per part/asm, I think this could help keep Alibre as is and at the same time fix the annoyance of save file prompts. I know I myself have to deal with this a lot with GLP files, for example if your whole project is driven by 1 GLP file, (main components) then you know exactly what I am talking about, a small change or even no change just a refresh and save of the GLP file will prompt a save for all the files tied to that GLP, I also had seen other save requests for files that I thought should not be, but I have better understanding after reading Max's replies in the other thread.

    For the SprutCAM example the default is one tick mark away from short, that is operations are saved with the calculated toolpath, thats typically what is needed, the other options make the file grow large, I know it does not translate to this in Alibre as those few values will not make any noticeable difference in the size.

    We might gain more speed when loading, of some parts/asm/sub asm with some other settings, if a number of things are ignored or loaded default (this will be up to the Alibre team and possibly user feedback to decide)

    I think some kind of "advanced Save Options" that will give the user a drop down of choices on what is saved, so that a lot of the annoyance could be avoided, as the user could change per part/asm, during a save as.

    Also this could be a Global settings that the user could select and make default for all parts/asm for example.

    With all that is said, good documentation in the help section should help the users make the choice and know when to use which setting (to be determined?)


    SprutCAM_ulX4jHxO1e.png SprutCAM_93xvUOA4DY.png SprutCAM_6y3z9FynzB.png SprutCAM_BysFrzs7O9.png Alibre_Design_p3u6CvsLPl.png
     
  14. Drutort

    Drutort Senior Member

    Now all of use will have a preference and opinion on what should or shouldn't be saved.

    I would probably define something like this:
    Hard change = actual dimensional changes by user or script/GLP etc..
    Soft changes = things that are not dimensional?
    internal file changes


    Personally I would like have a way to get rid of annoyance if possible, but at the same time I do enjoy having the part/asm save the position and view for example, so its not that easy.

    I think like Max had mentioned, its possible to put more logic into the process, I do not know if this would slow things down or possibly cause more bugs?

    What I would like is that if, I made no 'hard' dimensional changes; that is things like below should not prompt IMO a save: (or could be ignored)

    if I went into a sketch to look at a dimension or so but made NO change
    suppressed and then unsuppressed a feature
    If a value in the GLP file was made, but the part/asm did not use that value
    (if possible full regen but no changes done)
    others have asked, if the file was from previous version, dont bother saving it to new one?
    resizing of any window, or zoom, or cross sectional state 'soft changes'

    im sure im missing a few other things ;)
     
  15. bigseb

    bigseb Alibre Super User

    I have this. Mostly with drawing. Occasionally with part/assembly files. I generally don't report them because, honestly, I don't always have the time.
     
  16. Max

    Max Administrator Staff Member

    This isn't about what should or should not be saved. This is about when files should internally increment their version. The guiding principle there should be "if a change can be expressed in a drawing / bom / assembly, then it should increment, otherwise it should not".

    So for example, if you make a File Property change that turns Ambient Occlusion off, that will be saved. If that is the only thing you did, no geometry changed. So that save should not increment the internal version.

    If you turned off ambient occlusion and also changed a parameter - the parameter change is something that can be shown in a drawing because it affects geometry (or could). So in that case a version increment will also occur.
     
    Drutort and JST like this.
  17. albie0803

    albie0803 Alibre Super User

    I like this as a basis to work with.
     
  18. JST

    JST Alibre Super User

    Max: Note post 12, that file did originally ask to save on view change, but NOT if just opened and closed. I confirmed that prior to it changing to the behavior you see.

    It may be worth looking at it with respect to the view change also.
     
  19. simonb65

    simonb65 Alibre Super User

    100% agree. These are the only modifications that affect the part or assemblies geometric integrity and are subject to external revision and design control processes.
     
  20. GIOV

    GIOV Alibre Super User

    I like this:
    If a change can expressed in a new feature , then it should incremented, otherwise should not.
     

Share This Page