KOLite Activity Indicator Configuration - knockout-2.0

I am using KOLite on a project, and have everything working properly. The activity indicator works perfectly inside a button or in a small area.
My question is: Is there a way to configure the activity indicator per binding? For instance, it would be nice to have a large indicator in a div while records are loading, etc.
I hate to use a different indicator in certain places.

The one in kolite hooks into the control you nbind it to. However, you could create your own activity indicator for the page (or region) and wire up the code to turn it on and off in your kolite commands' completed handlers. Its a bit more custom, but there's nothing wrong with that.

Related

Is it possible to keep track of the Revit ribbon buttons which were clicked on?

I've been trying to figure out a way to record user interface actions to retrieve information about which ribbon buttons were clicked, but I've been unsuccessful so far.
I've spend a lot of time finding the related events in the API, but apparently there are none.
There are many ways to record user events in Revit. One of the simplest ways is to look at the journal file. It is always generated and stored automatically by Revit, so you don't have to do anything at all to obtain it. Look at its contents; all relevant user interactions are recorded there.
As said, there are other ways as well.
Afaik, recording which buttons are clicked is not officially supported and may be a bit tricky, cf. the Revit API discussion forum thread on obtaining button name using events for plugins working inside of another plugin.

How to filter uvm_info messages by type_id?

I need to filter all the uvm_info log messages by the type_id defined in it. For example, if I want to display only the uvm_info messages from a driver or a monitor, how can I effectively do it?
The UVM does not provide a mechanism to do this very easily. You would have to set the verbosity of everything to UVM_NONE from the top-level down, then go back and turn on just the messages from the drivers and monitors.
Finding al the drivers and monitors might also be difficult unless you gave specific component names, like starting with "drv" and "mon". Then you could use uvm_root::find_all("drv*",comps); and set the verbosity of those components in comps back to UVM_FULL.
It might be easier just to take the entire log file and filter the results you want using a (sed/awk/perl/python) script
How about a custom report catcher?
https://verificationacademy.com/verification-methodology-reference/uvm/docs_1.1d/html/files/base/uvm_report_catcher-svh.html
You can put this in your base test or top, then perhaps control this using a plusarg. A rudimentary example is here:
https://edaplayground.com/x/b4Fx
I think I am quite late to answer this question, however some time ago I wrote a program to filter UVM logs: https://github.com/Loneknight73/uvmlogfilter .
You can filter on, e.g., severity, id, time, component hierarchy and the message text.
That should help anyone who needs to filter verbose UVM logs.

How can I track detail view opens in Bixby?

I need to track which detail pages are opened and how often in result sets.
To do my own logging, I would need to send a javascript put command when the user opens the detail page.
How can I do that?
This is not possible right now in a straightforward way.
If you're feeling adventurous, you can try using lazy-source:
https://bixbydevelopers.com/dev/docs/reference/type/structure.property.lazy-source
Make sure that only the details view of your concept is using the lazy-property, so it isn't loaded on the list-of summaries, since as stated in the docs,
Bixby calls the lazy source when the property is referenced either in a layout or dialog.

Why do new Activities create new Windows on ChromeOS? How to constrain them to just one window?

Problem
I have a simple Android app with 3 activities: Login, Browse_Catalog, and View_Item. On ChromeOS, I expected the Activities to stack in a single window. Instead, each Activity is appearing in its own, independently managed window on ChromeOS. Why is that happening? And how do I stop that behavior?
Request
My hope is that there is some configuration detail to keep activities stacked in a single window. I've tried looking for some flag in the Intent that launches the Activity, or some setting in the Manifest, but haven't found anything that indicates this behavior is intentional, or that there is a way to disable it.
Technical Details
ChromeOS 76.0.3809.102 (Official Build)(64-bit)
Asus Chromebox
Android Studio 3.4.2
targetSdkVersion: 28
minSdkVersion: 25
jvmTarget: 1.8
Observations
No error messages as far as I can tell. Just an awful user experience with multiple windows leading the user to think there are three separate programs running.
The Activities that should be hidden on the backstack, aren't very responsive, the windowmanager allows them to be resized briefly before reasserting a z-ordering on the activities.
The windowmanager does allow me to close an Activity/window from the backstack (e.g. Browse Catalog, while Viewing Item), but then backing off from the top Activity goes nowhere.
Possible Workarounds that are Unsatisfactory
I can kind-of workaround this by making the Activities launch in full-screen, but it feels like a huge kludge. It doesn't prevent users from minimizing or resizing individual windows.
Perhaps I could do this as single activity with multiple fragments, but I don't want to invest that much work, unless I absolutely have to.
For posterity: My mistake was the Browse_Catalog Activity had a line in the Manifest
<activity ...
android:launchMode="singleInstance"
/>
This creates the Activity as a single "Task", and won't launch any additional Activities into that Task. Here's a page with more details about Activities, Tasks, and BackStack
The default behavior (aka android:launchMode="standard") is what I was expecting, so removing this spurious setting solved the problem.

How do I using Application Designer, add Failure Class field from different Maximo table to Work Order Tracking?

We want to "Categorize" our work orders more systematically. So far, we've been using Description, but we feel it is not a reliable way. We were hoping to use Failure Class as a starting point, but we find that having on a different tab discourages technicians and the help desk from classifying the work order.
Is it possible to add/duplicate the Failure Class field to Work Order Tracking screen?
Normally, I wouldn't ask, but was not clear if this was possible because Failure Class, Codes, and Tracking are different tables in Maximo. So, I wasn't sure how this would work exactly...
The simple answer is to use Application Designer's copy / paste functionality to duplicate the field. The specific field in question is on the top level of the Work Order Tracking application and facilitates interaction with the FAILURECODE attribute of the Main Object of the application, which is WORKORDER. Therefore, a copy / paste operation should be all you need. (Note: Application Designer's copy / paste functionality is used via that application's toolbar buttons, not Ctrl+C / Ctrl+V.) And if using Application Designer's copy / paste functionality doesn't work to your satisfaction, I would recommend exporting the XML for the application, copying the line of XML as desired and giving it a unique id, and importing the updated XML back in to Maximo. (Application Designer has toolbar buttons for exporting and importing an application's XML.)
You mentioned difficulty getting users to fill it in as a driver for asking the question. Another solution, which you can do as well as or instead of copying the field, is to specify the Failure Class on each Asset. Then, when an Asset is put on a Work Order, its Failure Class will be copied over, saving the users work and risk of not choosing correctly. And another idea is to highlight the Failure tab until a Failure Class is supplied.
And you also mentioned that the driver behind getting them to fill in the Failure Class, and etc, was to help categorize work. To that point, you should know that Failure Classes, in specific, and Failure Codes, in general, are intended to be used to help you determine what's going wrong with your assets, how often, and how the problems are being fixed. So, using them to categorize work is a bad idea. Instead, you should be using the Work Type field and Classifications, because categorizing work is what these are meant to be used for. The Work Type field is already on the Work Order tab, and Classifications fields are on the Specifications tab. You could copy the Classifications fields the same as I directed above for the Failure Class field.

Resources