I am attempting to popup a cfwindow in the center (or near where I click the mouse) of a very long list of names.
I have no problems getting the window to popup the first time in the middle of where ever I have scrolled to but after closing/hiding the window - subsequent clicks on different names shows the window at the same location as first opened and not in the middle of where the page has scrolled to.
How do I get the window to always open at the center of the page regardless of where I have scrolled down to and regardless of how many times I have already clicked to pop open the cfwindow?
<cfwindow name="wRally" title="View Rally Hours"
source="index.cfm?action=rally_hours&id={mainform:DYN_FORM_VAL}"
height="500" width="500"
bodystyle="margin-left: 0px; margin-top: 0px; padding-top: 0px;
padding-left: 0px; background-color: ffffff;"
refreshonshow="True" center="true" closable="true" draggable="true" ></cfwindow>
<script language="javascript">
function viewRally(myVAL) {
mainform.DYN_FORM_VAL.value = myVAL;
ColdFusion.Window.show("wRally");
}
</script>
onClick="viewRally('EMPLOYEE_ID_123');"
You might need to destroy and recreate the window each time see http://www.raymondcamden.com/index.cfm/2008/9/26/Ask-a-Jedi-Another-CFWINDOW-Example.
Related
Actually i want a nav-item to act like a dropdown on hover and on click it redirects to another link. I have already tried using css but it does work on hover but on click it shows drop down again istead of redirecting to another page. If someone knows about it then please explain it.
`
.dropdown:hover .dropdown-menu{
display: block;
margin-top: 0px;
}
.dropdown .dropdown-menu{
display: none;
}
`
THERE IS AN EDIT AT THE BOTTOM - look for "===== EDIT ===="
I am putting a fixed division at the top of the page. No problem with positioning it, but a problem comes up when I test the page by scrolling up and down.
Everything is fine with Chrome and IE but FF has a problem. The problem is that lines are "lost" under the fixed division. That is, the page is scrolled too far.
Here is the test page The entire source for the page is at the bottom of this question.
The division on the test page has width: 80%; margin-left: 50px; and opacity: 0.5 This allow you to see the lines underneath the division.
Go to the test page and highlight the last line at the bottom of the viewport. Highlighting the last line makes it easy to spot when you PgDn.
Now PgDn (or click the scroll bar - the bar, not the slider)
You can repeat the highlighting and PgDn and it should behave the same way.
With Chrome and IE, the highlighted line will still be visible, more importantly the lines following it will be visible.
With FF, the highlighted line, and one or two of the lines after it, winds up underneath the fixed division. The lines after the highlighted line are lost - not visible.
I've see this done successfully on other sites but I can't figure out what they are doing to make it work.
This page works correctly with FF, Chrome, and IE. There are others but I can't seem to find them right now.
Here is a page with the same problem as my test page It is different in that it "floats" the division until it is scrolled to the top and then it "fixes" it at the top. I've done this same float/fix thing and it also has the problem with FF. The test page I pointed you at, above, simply fixes the division to start with.
The funny thing about that page which has the same problem as mine is that it is a demo of how to put a fixed division at the top of the page and it doesn't work for FF
Another page with the problem of losing lines under the fixed division is yahoo.com. Lines are lost under the fixed division pretty much as is happening on my test page, but yahoo "loses" more lines than my test page.
Does anyone have any idea how to fix a division at the top and not lose lines underneath the division, lines which should be visible after the scroll? My test works for Chrome and IE but not for FF.
AND - wasn't there a code snippet link on the question page which you could use to provide demonstration code? I don't see it on this page where I'm typing the question.
<!DOCTYPE html>
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<title>Scroll Test</title>
</head>
<body style="margin-top: 0px;">
<div style="clear: both; opacity: 0.5; margin-left: 50px; width: 80%; background-color: red; top: 0px; position: fixed; height: 50px;"></div>
<div>
<script type="text/javascript">
for (i = 0; i <201; i++) {
document.writeln("*** " + i + "*************************************************************************************<br>");
}
</script>
</div>
</body>
</html>
By the way - the division (with the pink background) at the right hand side of this page has a problem when it get's fixed to the top of the viewport - the top is cut off. The only way to see the top is to scroll back up to the top of the page. This happens in FF, IE, and Chrome.
Where should I report this problem - about the "ask question page" - and provide the details?
===== EDIT ====
Thanks to user3137702, who told me to change the division to 100%. When I did that, the scrolling worked but initially when the page is loaded, lines #1 and #2 were under the fixed division.
I had the body set to margin: 0px; I changed that to margin-top: 50px; to make the first lines visible. I wasn't worried about the other margins - left, right, bottom, that's why I just changed the margin: 0px; to margin-top: 50px; - easiest to type.
but that through me back into the original error. After playing with it for a while, I found that unless margin-left: 0px; is set on the body tag, the scrolling won't work.
So, the complete solution is to have the fixed division set to width: 100%; and the body set to margin-left: 0px; and margin-top: nnpx, where nn is the height of the fixed division.
I'll add some JavaScript to set the body top margin based on the height of the fixed division so I don't have to mess around with it if the height of the fixed division changes.
I originally had width: 80px; on the division because I want the fixed division to show as less that the body width and centered.
I took the code that solves the problem and added a second division under the fixed division. The fixed division has background-color: transparent; and width: 100%. The nested div is where the content is and is set to width: 80% margin-left: auto; margin-right: auto to center it.
Now the it displays as I want it to and it scrolls properly.
Here's the new definition of the body down to the close of the fixed division's tag:
<body style="margin: 0px; margin-top: 50px;">
<div style="width: 100%; background-color: transparent; top: 0px; position: fixed;">
<div style="width: 80%; margin-left: auto; margin-right: auto; background-color: red; height: 50px;">
Contents of the child division within the fixed division
</div>
</div>
<div>
Here is a page incorporates all of the changes
Again, thank you user3137702, I'll select your answer.
Hold everything
I just played with the fixed page and have found that IE, FF, and Chrome all start to have problems with the scrolling as the viewport becomes shorter - as would happen if you resize the browser window or pull up something like FireBug.
I'm not going to spend any time figuring out the size that causes the browsers to start misbehaving, it would be a waste of time. Suffice to say IE and Chrome start having problems at larger heights than does FF. But the sizes are something that it is unlikely anyone will ever encounter. The viewport has to get pretty short to start the problems.
I can't explain exactly why it's happening, but it's the width that's messing up firefox; If you set the width of your fixed div to 100%, it works as you would expect.
<div style="background-color: red; top: 0px; left: 0px; position: fixed; height: 50px; width: 100%;">
</div>
I sometimes "protect" a custom UI control by placing a transparent div over the top of it. e.g. I have made an interactive data grid, and when I want to disable it, such as when I bring up a dialogue in front of it, I append a transparent div to the grid's outer container, with height and width stretched, so that it is not possible to click on anything. In the contrived example below, someFunction() will not get called when clicking where 'Blah' is, because the span will be covered by a transparent protector.
HTML:
<div class="control">
<span class="clickable-example" onclick="someFunction()">Blah</span>
<div class="protector"></div>
</div>
CSS:
.control {
position: absolute;
width: 100px;
height: 20px;
}
.clickable-example {
z-index: 0;
}
.protector {
position: absolute;
left: 0;
top: 0;
width: 100px;
height: 20px;
z-index: 1;
background: transparent;
}
However, I have noticed that in Internet Explorer (even 10), this doesn't work. It seems that a div with background set to transparent (either explicitly with CSS, or implicitly by not setting it at all), the div does not block what is underneath it. I thought this is wrong, but I can't actually see from the spec that it is wrong. The spec simply says that what is underneath will "shine through". It doesn't say whether or not the background should act like a piece of glass.
I've reverted to using a fully transparent image instead of the transparent div, but I wondered whether anyone has any further info on this. (The fact that it works with a transparent image proves that it's not a z-index problem).
I have a WinJS.UI.Flyout that I would like to have expand upward when content is added to it while it is visible. The flyout's anchor is at the bottom of the screen. If I call flyout.show(anchor, 'top'); it appears correctly at first, but then expands off the bottom of the screen when content is added. If I call flyout.show(anchor, 'bottom'); it expands upward, but it also covers over the anchor element, which I do not want.
This can be done by using -ms-flexbox display for the flyout and packing its content to the end.
flyout background can be set to transparent; it's size can be set to max possible; this way it serves as a outer container which aligns its content to the end. expandable content is placed inside another div flyout-content with background as white.
<div data-win-control="WinJS.UI.Flyout" id="flyout">
<div class="flyout-content">
expandable content here
expandable content here
expandable content here
expandable content here
</div>
</div>
css:
#flyout
{
background-color: transparent;
border: 0;
display: -ms-flexbox;
-ms-flex-pack: end;
-ms-flex-direction: column;
height: 400px;
}
.flyout-content
{
padding: 20px;
background-color: white;
}
I've encountered an odd behavior in a Windows8 app that I'm building with WinJS, javascript, and HTML. In a particular Page that I'm implementing, there are several divs that have CSS rules like this:
.col {
border: 1px solid none;
overflow-x: hidden;
overflow-y: auto;
height: 100%;
margin: 0px;
width: 100%;
}
The problem is when I invoke the main app bar by right clicking, the scrolled content in the div snaps to the top of the div. In other words, the scroll position of the div is lost. I've tried a host of ways to fix, but nothing has come up. How can I prevent the scrolled content from jumping around upon invoking the App Bar.
Thanks!
suggest to use -ms-grid for the page. The app bar will overlap the div in that case, which is ok and likely right behavior that you can see in other apps also.
html:
<div class="test5 fragment">
<header aria-label="Header content" role="banner">
<button class="win-backbutton" aria-label="Back" disabled type="button"></button>
<h1 class="titlearea win-type-ellipsis">
<span class="pagetitle">test page</span>
</h1>
</header>
<section class="content" aria-label="Main content" role="main">
<div class="test-content">
Text here.
</div>
</section>
</div>
<div id="appbar" data-win-control="WinJS.UI.AppBar">
<button data-win-control="WinJS.UI.AppBarCommand" data-win-options="{id:'cmd', label:'Command', icon:'placeholder'}" type="button"></button>
</div>
css:
.test5.fragment section[role=main] {
display: -ms-grid;
-ms-grid-rows: 1fr;
-ms-grid-columns: 1fr;
}
#Sushil is correct. AppBar is an overlay control, so you should place it next to the fragment div, not inside it. #Sushil's code shows how to do it.
Placing an appbar inside the fragment has performance penalties as it will need to be rendered every time a user navigates to that page. Another undesirable side effect is that all input to the appbar will propagate to the fragment. This is the problem you are facing.
In theory, you can listen to the various input events for mouse, keyboard, touch and call preventDefault on them. But it is not recommended.