There is no difference between isLoaded() and if (getCount() > 0) if a store contains at least one record always after loading.

Of course there is a difference. (getCount() > 0) does not say anything about loading, only about the number of records present. If you are lucky, at least one record made it to the store, so it is likely the store has done a load.If you are unlucky it has loaded but got zero records back. Your (getCount() > 0) then claims we never did a load. For fun: maybe someone can come up with a while loop where using this construction could cause serious problems.. anyone??

Let's assume that data required for combobox to create a new user. In that case role list cannot be empty, because each user of system must have some role. We are waiting for 'load' event or store.isLoading() or store.getCount(). There is no difference at all. I talking about that case only.

At any particular instant, a Store might be busy handling any number of the four "CRUD" request types: Create, Retrieve, Update, Destroy. It might be doling-out those requests one at a time or it might have sent them in large batches. And you really do not want to "tie" your software design to those details, which are by design supposed to be opaque to you.

Events serve [u]two[/i] important purposes in the JavaScript worlds: (1) they are a notification that something of interest to your code has occurred; but also (2) they are an opportunity to execute code at an opportune time. The notification mechanism is "a subroutine call," and that call is made at a point in time when the internal state of the calling object is stable and reliable. There are no messy "mutexes" and "tasks" and such: this is not a UNIX "signal." Although the event occurs asynchronously from the point-of-view of human time, it is synchronous with respect to the internal state of ExtJS which issued the call.

If you are "looking for a flag," there are a couple of subtle risks. One is that you are "busy waiting" on that flag. Another is that you might react to it at the wrong moment. Although JavaScript does not support "co-routines," lesser forms of inconsistency could happen.

Submit your request-object and put whatever additional attributes you need for your housekeeping purposes when the event-handling routine is called. This (JavaScript) strategy is robust and stable: follow it.

Haha! I tend to agree with realjax. It's simply not proper, and, even though it could work for a while (in the logic of the current developer), later on the code could be changed (or the database), and the numbers of results could be 0. A new developer wouldn't know, and would assume that IsLoaded is doing its job, but it actually wouldn't.

A little hack on the store to turn this attribute after a successful loading is a much better way. It's not hard enough to implement to look for another solution.

Check Store for lastOptions, if that exists then your Store has loaded at least once.

Thank you, worked like a treat! I'm not sure if this is version specific (4.1.1rc-2) but .on("load") only works when the store is loaded and I had trouble running through the same code twice as the event isnt fired again (obviously)