document function is working to get size and extenstion

Was the document just uploaded by the user on the very same interface?

yes

This is what I expected based on your error description.  Documents which have just been uploaded on the same interface are not available to the normal set of document parsing functions, including "document()", and trying to call it will result in an error. 

This is because, prior to the form being submitted, the documents are actually stored in a special place in the Appian File System that we don't have access to from the front-end (including the design side). 

Only after the task is submitted, are they moved out of that reserved space and into their target upload folder, at which point you can call "document()" on them.

This is what I expected based on your error description.  Documents which have just been uploaded on the same interface are not available to the normal set of document parsing functions, including "document()", and trying to call it will result in an error. 

This is because, prior to the form being submitted, the documents are actually stored in a special place in the Appian File System that we don't have access to from the front-end (including the design side). 

Only after the task is submitted, are they moved out of that reserved space and into their target upload folder, at which point you can call "document()" on them.

I would add, also, that the File Upload Field has a built-in way to validate on Extension and Size of uploaded files, so there should be no need to implement your own version of it at this point.

Yes i have did but i have a requirement  where i want to disable a button on the above mentioned conditions

NewBegineer said:

i want to disable a button on the above mentioned conditions

Unfortunately until something like my Ancient Feature Request is implemented, there is no direct supported way to do this with freshly-uploaded files.  The linked feature request would, of course, enable this use case as well as many other things.  If you feel so inclined, please visit that old thread, upvote it, and add a comment detailing your use case.

cc Peter Lewis (are there any engineers finally ready to take this on as their "free time project"?)

Hi vinayj0006,

a!localVariables(
  local!document,
  local!documentContent,
  local!documentSize,
  local!documentExtension,
  {
    a!fileUploadField(
      label: "Documents",
      target: cons!APP_TEMPORARY_FOLDER,
      maxSelections: 1,
      value: local!document,
      saveInto: {
        local!document,
        a!save(
          local!documentContent,
          property(
            property(
              a!fileUploadField(value: local!document),
              "contents",
              null
            ),
            "value",
            null
          )
        ),
        a!save(
          local!documentSize,
          property(
            local!documentContent,
            "fileSizeDisplay",
            null
          )
        ),
        a!save(
          local!documentExtension,
          property(local!documentContent, "extension", null)
        )
      }
    )
  }
)

You can use this code to get the metadata of uploaded document at runtime.

Please note that this method is very unsupported and potentially buggy (and could stop working after any arbitrary update to the behind-the-scenes component code).

Prior to the implementation of the file upload field "validations" parameters that enabled validating on these, I considered it (personally) acceptable to use this work-around if only for the sake of validating.  However now that we *can* validate on these aspects of uploaded files, directly using supported OOB functionality, I consider it too risky to use in any production sense (and won't personally recommend it or even directly hint at the capability anymore unless it's in a context where i know it'll be used only for testing or experimentation).  So I advise extreme caution / reservation, both for anyone considering adopting this approach, as well as for those providing it in threads here.

Totally agree with Mike's answer. I was in a assumption this is a legitimate approach.

NewBegineer , I would also recommended to not use this method keeping all the risks highlighted by Mike.

There has been some discussion on this internally, but I don't have much of an update at the moment unfortunately. Like Mike said, the best approach at the moment is still to validate using fv!files, and keep adding your use cases.

For instance, I'd be very interested in understanding more about this use case why it is important to disable the button over using the out-of-the-box validation behavior (where it prevents form submission).

Peter Lewis said:

I'd be very interested in understanding more about this use case why it is important to disable the button over using the out-of-the-box validation behavior (where it prevents form submission).

I can do the "devil's advocate" position on this one pretty easily: it's often desired to have a "Save Changes" button which skips *most* validations but still validates some more important things (for instance, validating that some text fields don't contain database-breaking lengths, or that there aren't files in place that would be problematically large).  Since the simple "validation group" concept doesn't actually handle this, one of my personal favorite workarounds is disabling the "save changes" button when something exists that shouldn't be saved.  (There was an entire debate about this just earlier this morning in the Discord).  But for this use case, of course, even that isn't directly possible.

Yeah that's a good use case, the context is helpful! I always appreciate a good use case because it gives a better picture into what the overall goal is - like in this case it would be great to have improvements to both validations AND document previews