I have to add that I have often received great help in this forum from folks like @s-molinari or @metalsadman and others. It is often difficult to get into the deep details of a particular problem, given the broad range of functionality offered by Quasar and Vue. I’m really impressed how you folks often come up with the right answers or at least pointers to the right solutions. Keep going!

After realizing that Heroku as the deployment environment for my Quasar app has restrictions with uploading/downloading of files, I’m now looking for some sample code how to use q-uploader to upload files to Amazon S3..

I’m not familiar with S3 yet and have used q-uploader so far only in a simple way, to upload files to the file system of the Quasar frontend app.

All I found so far as a boilerplate to start from is a tiny code snippet on the old Quasar site (https://forum.quasar-framework.org/topic/5382/how-to-use-q-uploader-in-quasar-app-deployed-on-heroku ) that uses q-uploader with so called signed S3 URLs.. It uses a q-uploader prop :url-factory=“getSignedUrl”, but I can’t find that prop in the API documentation of the current version of q-uploader on https://quasar.dev/vue-components/uploader#QUploader-API.

Is there another sample or Codepen how to use q-uploader to upload a file to Amazon S3?

Would greatly appreciate some advise.

All the best for Ravzan, get well soon. Your work is incredible, in terms of innovation, quality, and quantity.

As a first step, I tried a flex box as suggested by @metalsadman to align the q-toggles. Here is a code snippet that shows the concept, using class=“col-2” for each q-toggle, which means 2/12 of the available space in the row:

<div v-if="$q.screen.gt.xs" class="row full-width">
        <div class="col-2">
                <q-toggle
                      v-model="visibleColumnsMaterialEigenschaften"
                      val="schallSchutz"
                      label="Schallschutz"
                 />
        </div>

It took me a few attempts to find out that it needs class=“full-width” to work properly.

The result has up to 6 toggles per row that are aligned nicely:

@Jordan

The script section of my SPA on Heroku looks like this:

  "scripts": {
    "build": "quasar build",
    "start": "node front-end-server.js",
    "heroku-postbuild": "npm install --only=dev --no-shrinkwrap && npm run build"
  },

Wow…so I tried this combination of v-model=“toggleAllNormkategorienState” and @input=“toggleNormkategorien”…which is in my view a bit “creative”…at least not what I would have expected from the docs

On the first try, I got disappointed because it did not immediately work for me (neither control for table column visibility nor the ticking of q-toggle, worse than my original combination of @input= and value=).

But the additional trick to get this combination to work was to REMOVE the inverting of the toggleAllNormkategorienState from the toggleAllNormkategorien method. So, with that super-creative combination, it seems to WORK!!! Still need to a bit more testing to be 100% sure.

Thanks a lot for your always competent and quick help.

I compared your code again with mine, and have been able to find the cause why my q-table did not show up as “dense”. It was kind of a user error: I had put “dense” attributes on all checkboxes in my q-table, but not on the first Quasar related checkbox, which does the selection of a row in the table:

<q-td :auto-width="true">
        <q-checkbox v-model="props.selected" dense />
 </q-td>

With that “dense” property on the row selection checkbox and “dense” properties on all other checkboxes, my table is now “dense” as well:

@metalsadman - thanks a lot, I would not have caught the root cause without your Codepen!

I figured it out, but as part of testing, realize that I would prefer such a context menu to select a new node in the tree on the header slot, not the body slot of my q-tree.

In the body slot of my q-tree,

<q-menu touch position context-menu>
  <q-list dense>
    <q-item clickable @click="selectedKeyMyTree = prop.node._id">
      <q-item-section>Select node</q-item-section>
     </q-item>
  </q-list>
</q-menu>

does the above job to change node selection to the node under the context menu.

Is it possible to have such a context menu on the header slot that is able to change the selected node (and also offer some other actions)?

I did one more experiment, and got a context menu also working on the header-slot. Strangely, in the header slot I had to change the code that assigns the new node in the context menu to

<q-item  clickable @click="selectedKeyTreeBaustoffe = node._id">

The code I used in the body slot, if used in the header slot, results in an error that prop and node are undefined:

<q-item  clickable @click="selectedKeyTreeBaustoffe = prop.node._id">

Not sure why this works differently, the API doc looks the same for header and body.

Anyway, my last question is: How can I change the selected node in the context menu and subsequently trigger some other method when the user right clicks the context menu?

@FrankM - agree completely. Web sockets (compared to push notfications/service workers):

• are more powerful, given the richness of the socket.io API (except this “notify disconnected users” which is not important to me)

• are easier to set up

• can be used with http for dev environments

• can be easily integrated with Quasar. I now put the web socket setup into a Quasar boot file, so I have them available in all components through $socket.

• are not dependent on experimental browser functions (push notifications still are classified “experimental”, afaik)

Thanks for your advise.

I opened a PR with an example how to use vue-autonumeric with Quasar: https://github.com/quasarframework/quasar/pull/8568

@adagio - I took exactly the same route as you, I converted all my code from VMoney to VueAutoNumeric today.

The null handling of VMoney makes it unusable… My backend, like most apps, needs to distinguish null values from 0 numbers, while VMoney converts all null values to either 0 numbers or “0.0” decimal strings without explanation why and when. Very strange. I realized that VMoney issue too late and wasted 2 days struggling with it. I also realized VMoney is no longer maintained.

VueAutoumeric is so much better. The Quasar docs about third party mask processors which point to VMoney need an update to point to VueAutoNumeric instead.

@s-molinari: Thanks Scott. Yes, this QDecimal does probably what I need. I had seen it a while ago, but had decided to use v-money, because it had been officially “advertised” in the Quasar docs on https://quasar.dev/vue-components/input#Using-third-party-mask-processors

Now I found out that v-money (unless I did something terribly wrong in my adoption of it) has this ugly habit to convert all null values to decimal zeros, which is in conflict with the principles of my app. And it is no longer maintained. See https://github.com/vuejs-tips/v-money/issues/15 . Unfortunately I did not read this when I started to use it.

However, my initial tests with vue-autonumeric are very positive. It can be included in the same way into a q-field as v-money. It seems to have great support, and has a lot more options than v-money. So I’ll probably spend a day or so to replace all my uses of v-money with vue-autonumeric.

I would suggest we update the quasar docs in the above section with an example of how to include vue-autonumeric as a 3rd party component, very similar to the hint to v-money. I may open a doc PR for that (vaguely remember how to do it from another situation a year ago).

QDecimal as another potential alternative looks to be nicely integrated with Quasar. A sniff test with the first input field in the QDecimal demo however displays “0.0” after manual deletion of all field input, so it might have the same null issue as v-money, unless there is some option to influence it.

I have experimented with v-money, a component/directive to help with input of currency and decimal numbers. There is a sample for it in the Quasar docs.

And I had great difficulties with it in my tests, because it seems to convert all null values to 0.0 numbers or “0.0” strings, which means you cannot distinguish them from null values any more. Maybe I got it wrong, but in addition, it turns out that v-money is no longer maintained.

There is an alternative package vue-autonumeric on NPM which seems to have better support, https://www.npmjs.com/package/vue-autonumeric

With v-money you can wrap their <money> component into the control v-slot of a Quasar q-field (sample code in Quasar docs on https://quasar.dev/vue-components/input#Using-third-party-mask-processors ).

Does anyone know whether the same is possible with the <vue-autonumeric> component? Any experience or sample code?

@Adagio - wow, that v-money Codepen looks pretty powerful. I have similar headaches with decimal numbers - though in my app those are not currencies, but geometrical heights.

But I still have to digest how I could make use of this v-money stuff. At a first glance, the code looks very different from my current code, as I don’t even see q-input fields in the Codepen. It wraps a native HTML input field (v-money directive) or a new component (v-money component) within a q-field, rather than using a q-input as usual for data entry. I never used q-field, but at a first glance it seems to have the same or nearly the same props a q-input, so the conversion is hopefully not too difficult.

What worries me a bit playing with that Codepen for v-money is this “right to left” data entry (same as “reverse fill mask” in Quasar). That could be found unusual by users. used to normal Quasar q-inputs without reverse fill mask. Do you know whether it can be changed?

@suleiman_as , @walfin - thanks, that’s not explained in the docs. I may open a doc PR for it.

What is the difference between “disable” and “readonly” in form components, like q-input, q-select, etc.?

I’m aware of the visual differences (e.g. “disabled” icon shows at mouseover for disabled fields).

But what other differences exist? I would expect that e.g. for a q-select, I can open the pulldown menu with options, if readonly (without ability to change the selected options), and I can’t open the options pulldown if disabled…but a short test seems like I can’t open the options pulldown in either case.

So I’m not sure when to use one vs. the other, and why the two exist.

Isn’t this influenced by the language setting in quasar.conf? I have this:

framework: {
lang: “de”
}

Decimal numbers in q-inputs show up as “1,25”, not “1.25” for my Quasar app.

The corresponding v-model always has “1.25” though, which is needed by JS, as far as I understand it. This conversion seems to happen by the browser, Vue, or Quasar.

@jc_71950 - today my Heroku build (which has been working successfully until yesterday, with the above statement) failed, with strange dependency related errors. So now I’ve been hit by the same issue like you a few days earlier.

After several unsuccessful attempts to correct it; I removed the above statement…now the Heroku build works again, without that statement. Very strange, not sure what changed at Heroku, NPM, or Quasar, causing that issue.

@beets - thanks for this pointer. At a first glance it seems to do what I need.

Since I did quite amazing things with nested (and accordeon style) Quasar expansion items, it would be a bit unfortunate though to have to use another Vue component for this.

Another alternative might be q-carousel - maybe with imbedding an expansion-item within a carousel item.