According to the adsense documentation, maxTop is "Required when the ad unit is above the search results. Use this parameter to specify the number of ads to be shown on the top ad unit."
https://developers.google.com/custom-search-ads/s/docs/reference
Why do we need to do so? What if there are contents, little or lengthy, before the TOP ad? Is this still required?
maxTop isn't technically required, but when you use that instead of number it tells CSA that that block is the TOP block. The TOP block is generally more valuable since it's more likely to be seen so it's best to tell the system when you have a block like that.
If you have some content before it (a nav bar, search bars, etc) that's probably fine. If you have a lot of content before it such that the user would have to scroll to see the ads then maxTop probably doesn't make sense.
Both number and maxTop will act as the max number of ads that should be shown in that block. The only difference is that it lets the system know which block is on the top of the page, and maxTop can only be used on the first block in the page. If you have multiple blocks all others must use number, regardless of what you use for the first block.
Related
I understand from documentation and several related StackOverflow posts that window.parent, if there is no other parent, will self-reference and thus never be undefined.
I can't seem to find a decent reason as to why this is. JavaScript does have its idiosyncrasies, but this one just seems odd.
MSDN simply states that
If the current window doesn’t have a parent, i.e. it occupies the whole browser window, Parent returns the current window’s Window object.
MDN states
If a window does not have a parent, its parent property is a reference to itself.
And the W3 standard itself
The value of the parent attribute of a Window object MUST be the parent document's Window object or the document's Window object if there is no parent document
I've not seen other languages acting like this, what reason is there for this self-referencing design? Wouldn't 'null' or 'undefined' make for a more obvious situation when you hit the topmost element in a window?
So, why?
When working with iframes, developers often automate processes which navigate through windows. While the algorithms at their core will consist of the same basic logic, the conceptual approaches will differ.
Instead of working in a parent-children manner, sometimes the developer will craft the system in such a way that it will seem not to look for the parent, but simply for the right window to use. The one that controls (not necessarily holds) the area where the code is currently running.
In the case of such approaches, it would be conceptually weird for the program to return "false" or "undefined" when asking it a refference to the "right" window, because there must be one.
For instance, Bob is programming:
Bob: I embedded an iframe! Alright, let me just play around with the window that contains my entire iframe (not the window of the iframe itself)
Bob: What? Null? But I don't get it, my iframe is up & running, how can there not be any window which controls it?
I'm just saying that window.parent may not be meant to literally and strictly get the parent from the DOM (like .parentElement does), but more like to point to the window which absolutely wraps not only your script, but also everything else that wraps it at lower levels.
In the case of the topmost window (where your script is being executed), that statement may return the same window because, not having any oher window more important than it, it simply becomes 'the right one' to use when looking for the superior container.
I hope I make some sense.
I would say that this helps with window communication. When loading third party content, it might leverage window.parent.postMessage as it's form of communicating with it's implementation context, but it might be implemented with no parent window. An html page loading content in an iframe would have its own window as the iframe windows parent, but content loaded into something like a browser plugin such as an electron webview would have no parent window so the postmessage would fail and the implementing context would not be able to listen for that event. So basically it just allows for a safety net to allow devs to always be able to use window.parent because they might not know if their code will be running from window.top or not.
I assume this is just unfortunate naming. That property could have been better named something like 'parentOrCurrentWindow'.
If what you want is 'parent or current window' then being able to access that as just 'parent' makes your code a little shorter. And if you know that is so then it does not matter much. You could say it is better to get hold of SOME window than null.
But note this has nothing to do with JavaScript the language. This is about the DOM-model implemented by browsers. The DOM model could be improved to include two properties 'parentOrCurrent' and 'parentOrNull'. And in fact you could assign those variables in your own code to make it clear which one you are talking about.
I'm automating an app that shows some overlay messages anywhere on the app for several scenarios, such as app installed for the first time etc. (I'm fairly new to Robotium too.)
The overlay displays a text that goes away by swiping or clicking on it. Also, there are different types of these overlays with different unique text on it. (let's call it Activity A)
I wanted to create a robust test case that handles this case gracefully. From the test's perspective we won't know that the activity A will be present all the time. But I want to recover from the scenario if it does, by writing a method that I can call any time. Currently, the tearDown method gets called since my expected activity name doesn't match.
Also, even if the activity A exists, there are other predefined overlay texts too. So, if I use solo.waitForText("abc") to check for text "abc", I may see the overlay 2 with the text "pqr" instead.
So I was looking for a way to automate this, and I can't use solo.assertCurrentActivity() or solo.waitForActivity methods as they just stop the execution after the first failure.
So any guidance is appreciated!
All the waitFor methods return a boolean. So you can use waitForActivity() exactly as you want to. If the Activity doesn't exist it will return false.
You can check which Activity is current:
Activity current = solo.getCurrentActivity();
I have three controllers in an area in my application that I want to break out from the rest of the area. For instance I would like a url like /Area/Approve/Timesheet/Action and then be able to still have /Area/Timesheet/Action that both have completely different functionality (one approves the time sheet as a supervisor, the other fills out the time sheet as an employee). Is this possible?
Yes, it's definitely possible, as long as you have the right routes set up. Remember that even though the default MVC Area template shows one particular route pattern, in the end, all the routes go into the same global routing table, so as long as you set the right URL patterns, you should be good to go.
If you're having trouble with any particular set of routes, please specify what you have and what isn't working.
I have to maintain a part of an old Windows VB6 project (so, don't tell me to migrate-it to VB.NET). This program embeds the well known webbrowser control (IE) in which it loads local HTML files (containing different stats, but doesn't matter). Knowing we don't want any scroll bar in the web browser view (even if HTML page is longer than the webbrowser window, we just need to see what it's on top), we manage DOM on DocumentComplete event like this :
Private Sub wb_DocumentComplete(ByVal pDisp As Object, URL As Variant)
wb.Document.documentElement.Style.overflow = "hidden"
ProcessWithDStats
End Sub
All sounds right and the vertical scrollbar well disappear, but now, I need to add some stuff in the ProcessWithDStats sub (a big sub calling a lot of functions) which need to be sure the previous DOM operation is totally completed (I mean : scrollbar hidden and it's content re-justified accordingly to this new width w/o scrollbar).
So, how to do ?
At this time, ProcessWithDStats is executed before DOM management really finish to be rendered !
Until now, here are my attempts :
I've tried to add a scrollbar testing (comparing doc width and browser client area one) between the two lines, but it doesn't work : test is OK, but reflow of text (because of this change of width when scrollbar disappear) has not enough time for being applied before ProcessWithDStats is engaged.
I've tried to Sleep(), but it locks entire program (webbrowser rendering included)
Well is there a way to wait for real application of the given DOM management in this WebBrowser control ?
I mean something like :
Do
Doevents
Loop Until [DOM modification and rendering completed]
you need to do this... at the very least.
Do
Sleep 100
Doevents
Loop Until wb.Busy = False And wb.ReadyState = 4
On your version the .Busy may be called .IsBusy but are the same thing.
Also, there are additional things you should do if you want to truely know if a browser is done loading, read some of my previous answers if you want to know more, or need more accuracy than the above, but what i have included for you is for sure a much better solution than you currently have. Let me know if you need it to work on 100% of websites or just a select few, if a select few than this simple method may be enough.
Let me know hwo it goes anyway, cheers.
In my app I want the user to type names into a UITextField (or equivalent) and then when they press return, it will put that word(s) in a blue bubble that's usually associated with tags. The cursor then moves to the end where they can add more "tags".
This can be seen when adding contacts in the To, CC & BCC fields in the Mail app, and also when selecting contacts in the Messages app.
How is this done? Is it something that's provided in the UIKit or available somewhere else?
Many thanks,
Michael
Venmo just open sourced their token field.
https://github.com/venmo/VENTokenField.git
edited:
The equivalent control in desktop Cocoa is an NSTokenField, but there doesn't seem to be an equivalent for Cocoa Touch.
Since iOS 13 there exists UISearchTextField.
https://developer.apple.com/documentation/uikit/uisearchtextfield
You can see that component in action in the Photos App.
That should fit for many use cases. By removing the leftView you can also get rid of the search icon.
But be aware: You can‘t mix text and tokens at various positions.
From the docs:
Tokens always occur contiguously before any text in the search field.
Adding this here for reference:
Feel free to check out TaggerKit (a library I made), it's more or less what OP was talking about. You can basically add tags functionality to your app by just adding a view and a couple of properties.
I dont think you can do it with any built in functionality in the SDK, never seen such a feature. What you could do however is implement it yourself, have some custom blue button with some text over it, and when the user hits return you can have some code that takes the text and returns you the button that you need, shouldnt be too bad to implement