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.
Related
this is my very first entry here, may it not be the last....
I am having a bit of a struggle with some GUI stuff.
I really have an animation up front my eyes and it should look like the following: using c# with desktop application.
This Form looks like a login window with server address, username and pw textboxes and with a connect button as well, so nothing special. Size wise it can be small or at least same as size as the turned window. doesnt matter at the end.
once you entered your credentials and all turns out to be fine, connection is there and valid.
The main Form is suppost to flip then (doesnt matter horizontal or vertical),
and shows you your options you got then in this newly window. kind of an animated sign, that you are logged in and have now these options.
But the flip is suppost to stay on the same place. Like a card flip or a coin flip, but just the whole form and it ends then at the same place as before.
(sounds really wired to explain)
This can also be done with a new form poping up, just with a animated turn over, no problem with that.
And this is exactly where I am stuck.
I really cant find any information on how this would look like in code or even in animation.
I am using c# and the basic project started as a desktop application project, which it will be at the end.
Its been a while since my last coding, please be gentle.
i know there are plenty of entries in here also in google as well, but i didnt found anything which will do this for the main window as a total. images etc: yes, but for the whole form: no.
Any help out there?
May be tehr eis a trick i am not aware of? Its been a while since the last coding work, I need to admit that.#greyhairsarecomming
many thanks in advance! much appreciated
kind regards TG
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.
Firefox addon. I'm porting an existing addon to a restartless one. I have a panel with a lot of UI elements (mostly boxes/description and images) in it, and it is very convenient for me to define the panel elements in an XUL overlay file. I will have lots of bloated js code if I don't.
The panel element (parent) itself is created in code dynamically, and then I use loadOverlay, wait for the 'merged' event and then append the panel element's children from the overlayed document. I also make sure that the elements are cleaned up upon a remove.
However, using overlays will most probably won't pass an AMO review. And some of the reasons I think are :
In most cases overlay elements will cause problems while removing (eg: toolbar buttons remembering their positions etc.)
There are problems with attaching js/css files in an overlay file.
loadOverlay is buggy (496320, 330458)
And here are my inferences :
loadOverlay() API itself is not deprecated - in fact it is 'not frozen and may change later' - which means possibly it will be use-able in future.
The bug that a second overlay load fails, is not applicable in my case, as I don't initialize without an overlay merge.
Using static overlay for preference windows etc. is perfectly acceptable as of now.
The panel in my case behaves a lot like a preference window (which is brought up on demand and cleaned up upon addon removal)
I don't have any js/css attached to the overlay, nor any event listeners for the elements. The overlay is only used to define boxes and description text - nothing more.
So considering these, is it acceptable to use overlays and loadOverlay() for a restartless addon ? If not, is there an alternative ?
About overlays, by checking source code of restartless addon that extend existing addon (like ehh), I see the overlay.xul is auto merged with the existing addon's. So it shouldn't be a problem to use overlay.
The object is to Show-Hide text located under their respective Titles, so a User reads the title and shows or hides text belonging to that title if the User wants to read more.
I tried whatever I could find so far on here, we're talking dynamically setting text coming from a spreadsheet, can't use IDs, must work with .class, must be missing something, I have this piece of code:
... html.push('<div class="comments">' + comment + '</div></div></div>');
but when I try this Show-Hide code nothing happens, even if the error console shows nothing. Basically I want to Show-Hide the .comments class divs with a show-hide toggle link located under each of them. I say them because the .comments divs are reproduced dynamically while extracting text coming from Google spreadsheet cells/row (one .comments div per spreadsheet row). I tried .next, child and parent but they all divorced me so I dunno looks like a dynamic issue. So far I only managed to globally toggle all divs to a visible or hidden state but I need to toggle independantly individual divs.
I prefer a jQuery solution but whatever worked so far was achieved with native javascript.
Note: If a cross-browser truncate function which would append a more-less link after a number of words (var) in each .comments divs would be easier to implement then I would gladly take that option. Thx for any help, remember I am still learning lol!
I have been working on an entirely JS UI project and have brought myself to using $('', { properties }).appendTo(BaseElement) to work best for adding HTML elements because it appropriately manipulates the DOM every time.
If you are having good luck with push elsewhere, however, breakpointing on the line where you do your $('.class').hide() and see what $('.class').length is. Alternately, you can just add alert($('.class').length) to your code if you are unable to breakpoint the code. If it is 0, then your elements have not been properly added to the DOM. Changing to append will ensure they are part of the DOM and therefore targetable via JQuery.
I am trying to bring my secondary form to the Foreground, however when I do
MyForm.Show; // It may be hidden, therefore show it first
SetForegroundWindow(MyForm.Handle);
my Main Form appears aswell. The only way I can prevent that is to do MainForm.Hide; but I got to avoid that.
The idea is to have my secondary form appear on top of another application, without my Main Form having to do so as well.
If you consider to make another application for this functionality, then you may also consider the following compromise: minimize the MainForm to the taskbar (rather than hiding it) to prevent it popping up when activating another form.
If so, then try this answer. It does add an extra icon to your taskbar for the secondary form, but I guess that'll be no problem since a different application would either. However, if the MainForm is nót minimized but obfuscated by other windows, activating the secondary form wíll also popup the MainForm, just like you are experiencing now.
And for the completeness of this answer's sake, but not by any means meant as advice: this answer describes a (somewhat experimental) construction to make fully independent windows. The little time I tested that solution, it seemed to work, but be prepared not counting any longer on the full/default functionality of the VCL.
Try settings the state of the form to fsAlwaysOnTop.