I'm newest in web.
I want customize default scroll-bar in ag-grid. I try use ngx-scrollbar for this. In sources ngx-scrollbar I found that ngx-scrollbar using ng-content for wrapping elements(link to github source file). If wrap ag-grid-angular element then scrolling even doesn't shows because content doesn't overflow ag-grid-angular content because oveflow happen in div with class .ag-body-viewport where using stock srolls. In order to achieve needed effect I wish pass DOM element with class .ag-body-viewport to ng-content of ngx-scrollbar. Is it possible?
More info here github issue but I don't use Nice Scroll or Perfect Scrollbar
I want use ngx-scrollbar because it has capability of customization.
UPDATE
I can pass DOM element to ng-content using next sintax(agGridViewport is native element):
<ng-scrollbar>
{{ agGridViewport }}
<ng-scrollbar>
but it pass element like a copy of real DOM object but I want pass this like a refence.
Now I got UI like a stack style:
[rendered real ag-grid-angular]
[rendered ng-scrollbar with his content]
But it isn't that I need. Also I got bad rendering with artifacts and even some components doesn't appear. Now I want to try use Renderer2 for putting ng-scrollbar element between two DOM elements in tree(.ag-body-viewport-wrapper and .ag-body-viewport). But I think it's very bad idea because Renderer2 doesn't have methods for putting elements between DOM elements in tree and my code will be very unlify and complicated :( It's must be like injection.
No, I can not do injection in DOM with Angular tools. It's bad idea do it and it is not possible now. AgGrid doesn't support customization with tools like ngx-scrollbar which using ng-content for wrapping components and other elements. May be better way using other tools which working by another way or using webkit customization which supports not all web browsers.
UPDATE
Also I try to use smooth-scrollbar. I managed to get better result. I bind him to element .ag-body-viewport. It works fine but it scrolling only content of grid without header be careful. smooth-scroll bar doesn't have options for horizontal and vertical scrollbar as a different units. I know how issue can be solve. Vertical scrollbar must be bind to .ag-body-viewport and horizaontal scrollbar must be bind to .ag-root. If your can find scrollbar which let you do it that you can solve this problem. May be I write special component for Angular in near future and then add link to this answer. If you do it faster you can add yourself link or you can add link to already existing packages.
Related
I have spied an input text box using the Application Modeller of Blue Prism and was able to successfully highlight the text box using the below XPath:
/HTML/BODY(1)/DIV(4)/main(1)/DIV(1)/DIV(1)/DIV(1)/DIV(2)/DIV(1)/DIV(1)/DIV(2)/IFRAME(1)/HTML/BODY(1)/DIV(2)/FORM(1)/DIV(3)/TABLE(2)/TBODY(1)/TR(1)/TD(1)/DIV(1)/DIV(1)/DIV(1)/DIV(2)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/SPAN(1)/DIV(1)/DIV(2)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/DIV(1)/TABLE(1)/TBODY(1)/TR(1)/TD(1)/INPUT(1)
I wanted to use a more robust XPath and to achieve that I was trying to use the below XPath:
//*[#id="CT"]/div/div/div/div[1]/div[1]/table/tbody[1]/tr/td/input[1]
The above XPath was identifying the element correctly in Chrome but was getting the below error message when trying the same in Blue Prism:
Error - Highlighting results - Object reference not set to an instance of an object.
Let me know if I am doing anything incorrectly.
Sorry for replying to a pretty old one! The workaround we've devised for this scenario (where making the path dynamic requires too long of a loop / search) is to use Jquery snippets. If the page is using jquery it is trivial to execute these queries very quickly using the blue prism capability of executing javascript functions.
And we put in an enhancement request, because it'd be supremely useful functionality.
Update: As a user points out below, the vanilla js querySelector method is probably safer and more future proof than using jquery if it is possible to be used.
Blue Prism does not fully support the XPath spec; alas the construct you're attempting to use here won't work.
Alternatively, you can set the Path attribute of an application modeler entry to be Dynamic, which allows you to insert dynamic parameters from the process/object level to pinpoint elements you'd like to interact with.
Unfortunately Blue Prism doesn't actually use "real" XPaths, but only an extremely limited subset: Absolute paths without wildcards. (Note: It is technically possible to match the XPath to a string with wildcards, but this seemingly causes BP to check every single element in the document, and is so slow it is almost never the right solution.)
For cases where an element can't be robustly identified via the BP application modeler (maybe because it requires complex or dynamic selectors), my workaround is to inject a JS snippet. JS can select elements much more reliably, and it can then generate the BluePrism path for that element.
Returning data from JS to BluePrism is not trivial, but one of the nicer solutions is to have JS create a <script id="_output"> element, put JSON inside it, then have BluePrism read the contents of this element.
I’m using a NativeScript <ListView> and I’m trying to get access to the individual elements in each element’s <ListView.itemTemplate>. To give a concrete example, given this code snippet, how do I access each <GridLayout>?
<ListView>
<ListView.itemTemplate>
<GridLayout>...</GridLayout>
</ListView.itemTemplate>
</ListView>
I know that I can add a loaded event to each <GridLayout>—i.e. <GridLayout loaded="myEventHandler">—however, for my use case I need to change attributes on the <GridLayout> after an unrelated event occurs.
Theoretically I could use the loaded event to build an array of all <GridLayout>s in a <ListView.itemTemplate>, and then use that array to perform actions, but that just seems hacky. It seems like there has to be a better way. Any ideas?
Manipulating the visual tree for a list view item doesn't seem like the most robust approach here. Consider the following scenario:
An item gets rendered to the screen.
Your code kicks in and modifies the visual container's tree.
The user scrolls, or something else happens, and the list view reuses the visual container for another item. Your new item now looks broken.
I'd implement this using bindings and, if things get hairy, an appropriate view model that makes bindings straightforward.
You can use the nativescript-dom plugin. The getElementsByClassName actually has code to traverse the ListView's children. Unfortunately after I discovered the issue and put in the bug report into the NS Common Components repo -- I totally forgot to make the same changes to the getElementsByTagName and getElementById functions in the nativescript-dom plugin.
So using getElementsByClassName if you assign it a class name should work right now. Otherwise; I'll probably do an update to the library later this week that will have the listview children traversal code in it for the other two methods.
Update: I've released a new version of nativescript-dom that allows all three getElement* to work on ListView children.
I think you may be able to give the each gridview and id dynamically using something like id="gridView{{$index}}" then use page.getViewById('gridView1') for example. Can't test it out at the moment, but I think that would work.
I have an application where I need to display metrics. The application needs to display a separate vertical section for each metric. When I started this, there were only 5 metrics so I naively created a template with 5 regions, one for each metric I needed to display. Now, new metrics need to be added and I want to avoid adding "hardcoded" region divs in the template. I want to refactor this and create the required regions dynamically at startup time based on some configuration data.
So I have been looking at the latest Marionette release and in question "Dynamically add regions to Marionette layout", Derick Bailey mentions that Marionette v1.0 supports dynamic regions in Layouts through addRegion(), as in:
var layout = new MyLayout();
layout.render()
layout.addRegion("someRegion", "#some-element");
layout.someRegion.show(new MyView());
I have tried that in my code (using Marionette 1.0.2) and I am not getting it to work. I don't have a div with id="some-element" in my template and I suspect this could be the reason. I was hoping that Marionette would create that div itself.
Perhaps my expectation of what dynamically adding a region means is wrong. So my first question is: when adding regions dynamically to a layout, must the element id passed in the addRegion() function already exist in the layout?
If so, then I am back to the problem of having to "burn" in the template those divs for the regions to attach themselves too. My follow-up question is then: What is the best way of doing this in a data-driven fashion? Is it a matter of writing my own render() function so that the right set of divs get created? Or perhaps providing my Layout with a model object that will contain data which the template can then iterate through to create the necessary divs? How do we add regions dynamically to a Layout object if we don't know in advance how many regions we will actually need?
Aa #aaronfay specified, we need to use jQuery to create the element on the page. Here is some sample code:
var layout = new MyLayout();
layout.render()
var regionName = "dynamicRegion";
layout.$el.append('<div id="'+regionName+'"></div>');
layout.addRegion("someRegion", "#"+regionName);
layout.someRegion.show(new MyView());
I believe you would need to use jQuery (or similar) to create the element on the page. A Region expects the element to exist.
Otherwise, I believe your answer is here.
I am sure this is on here already...
I want to be able to disable autocomplete for some CMS generated form fields with some frontend javascript code, preferably Prototype but neat javascript will do if it has no cross-browser problems.
I have ids for my boxes and I am not using some clever 'prototype autocomplete' (that seems to stuff the Google results on this). Regular browser autocomplete is what I want to turn off and not for the entire form.
Knew I would find it as soon as I asked:
$$('.MacGuffin')[1].setAttribute('autocomplete', 'off');
$$('.MacGuffin')[7].setAttribute('autocomplete', 'off');
That is specifying elements by class rather than id.
Currently, my anythingslider has too many slides to fit in the wrapper without wrapping some elements below the others. This should make sense to users of this plugin. I'd like to show/hide some of the invisible elements as the back/forward buttons are clicked. My problem so far is that the plugin is looking for elements that have been hidden after it's been initialized.
Is there a way to re-initialize the plugin so all slides are up-to-date on the fly?
I really hope this makes some sense!
Thanks.
This functionality was added in AnythingSlider version 1.5... there have been a few updates since ;)
Calling anythingSlider(); will re initialize the the slider. No need to specify the options. Just call $("#element").anythingSlider();