I have a textbox that I am attaching jQuery UI's Autocomplete functionality to and I am using CSS to give it a max height via the example here. My problem is that doing this causes the z-index problem that bgiframe solves to come back again, but in a different way. The initial autocomplete menu is above all the controls underneath it, but when I begin to scroll the autocomplete menu falls behind them.
Any suggestions?
EDIT:
This is purely an IE6 bug.
As you can see, after scrolling down the autocomplete falls behind the other controls.
I could solve the problem by replacing offsetHeight by scrollHeight in the following line (from jquery.bgiframe.js) :
height:'+(s.height=='auto'?'expression(this.parentNode.offsetHeight+\'px\')':prop(s.height))+';'+
This change solved the bug for the autocomplete fields with vertical scrollbars. I could not spot any regression in other kinds of dialogs (but I did not run extensive tests).
You need to reverse the z-index order of the form elements (or their containers) using javascript. I.e., "Social Worker" has the lowest, "DX Code" the highest z-index.
You could change the offsetHeight to scrollHeight, like Siggen says, but I have encountered problems when there is only 1 result returned from the autocomplete. The 1 result is squished into a window that only like 2 pxs high.
I found a fix though.
When you have a data.length<2, you should use the offsetHeight, rather than the scrollHeight.
You have to modify autocomplete.js.
Locate this code:
if($.fn.bgiframe)list.bgiframe();
And make it this:
if($.fn.bgiframe){
if(data.length<2)
list.bgiframe({height:'expression(this.parentNode.offsetHeight+\'px\')'});
else
list.bgiframe();
}
Remember, this code should be used in combination with Siggen's fix.
I have used a combination of both parameter for the height like this:
'height:'+(s.height=='auto'?'expression(Math.max(this.parentNode.offsetHeight,this.parentNode.scrollHeight)+\'px\')':prop(s.height))+';'
Look at the max function. Now it is good with no scroll bar (shorter list and longer list as well)
and now the autocomplete component looks perfect in IE6.
Related
I have a ons-page element that I want to customize the scrolling for. There are a few things I'd like to achieve, but mostly I want to understand what's going on.
By default, the page has -webkit-overflow-scrolling: touch. This is undesirable for two reasons:
The area "behind" the page shown during overflow is just plain white
I have no hooks to take action on over scroll. I'd like to add pull to refresh mechanics.
I've tried working with iScroll, but the behavior I'm seeing is that if I declare my scrollable element to be inside of the page, it calculates the full element height as the visible height. If I declare my scrollable element to be the page, I can move the page around, but not the content within the page.
I'm guessing some of this is related to "using native scrolling where it can", but I don't really understand how that's implemented, so I'm not really sure.
Any ideas?
Onsen UI doesn't support pull-to refresh as default.
How about using this library?
https://github.com/mgcrea/angular-pull-to-refresh
This is a library for angularJS.
P.S
Now Onsen UI support pull-to-refresh. http://onsen.io/reference/ons-pull-hook.html
I'm relatively new to programming and my problem is with a TMainMenu on my form.
I researched a lot (a whole lot) of sites for a solution, but haven't found any that solves this exact problem.
The main menu won't resize, not even when I change the fontsize using Screen.MenuFont.Size. I tried setting the Height property in the OnMeasureItem handler, I tried resizing the images and sub-menuitems at both design- and runtime, I even tried capturing Windows' message WMDrawItem and changing it's parameter before passing it on...
The menu items in the component are resized accordingly, but the vertical height of the menubar itself isn't. (the line seen on the picture below cutting through the icons)
Is there an easy solution to this, like setting some well hidden height property somewhere?
Or do I have to rewrite half of delphi's code to achieve my goal?
Help with code examples are appreciated. :-)
Here's an image:
I am using Delphi 7 on a Win7 machine.
The height of the menu bar is a Windows metric setting. Thus it is valid system wide - not only for your application. If at all, it can only be changed via the display settings of Windows itself.
I would recommend to use TActionMainMenuBar instead. It is much more flexible then the TMainMenu.
You can change the font of the menu bar very easy as well.
I am trying to swap two TD elements in table on Drag&Drop. I found this plugin Swappable and it works in some way. But when I drag some element the cursor change position to some specific value. I do not want changing cursor position. But when I rework this plugin it stops work.
Does anyone have experience with it or know about any other plugin?
Thanks,
Zbynek
Usually I use the jQuery sortable. It does pretty much want you want. You can use it in a table too.
Then I do my stuff (including ajax updates) in a function setted in the receive event
Did you try the JQuery Sortable() option?
See http://jqueryui.com/sortable/#display-grid
I'm having an odd problem with jQuery draggable this morning, I wonder if anyone else has come across this.
I have many small divs inside a large div. They are absolutely positioned: "position:absolute" in CSS for their class, with the actual position itself calculated and set in JS on demand.
Now I'm adding functionality to allow these divs to be draggable.
But, as soon as I make one draggable, it is given "position:relative" directly on the element, which as you might imagine, seriously messes up the on screen position.
Does anyone know why it changes the "position" like this or how to tell it not to?
EDIT:
Just realised there is a rather obvious answer staring me in the face - !important on my position:absolute! This seems to fix it. BUT I'm still interested if anyone knows why it sets "position: relative" like this (and doesn't either make it configurable or check first if it needs position)...I'm wondering what problems I've just stored up for myself ;-)
"I came across the same problem today. The reason was I was applying draggable() on a dynamically created element. I was 'later' appending it to dom. The element should be in dom when you apply draggable() (if style is being applied by a class). In short, when it finds no position attached with the element , it adds relative." - Jashwant
Firs do: .append(jElement) Then: jElement.draggable()
For some reason Jashwant put his answer in the comment to the question. So I thought it will be convenient to other to repost it here.
It also happened to me, but only on Chrome. Reason?
It was like this:
$("#div-popup").draggable({ handle: ".top", containment: 'document'});
Then I removed the containment parameter, like this:
$("#div-popup").draggable({ handle: ".top"});
So it's about the Browser (Chrome in this case), which sets position to Relative when you specify which containment the element will be draggable.
in my case it seems to be a race condition between the stylesheets and javascript loading...
i realized i'd made the mistake of including the stylesheets AFTER the javascript in the document head. they should be included BEFORE the javascript because $(document).ready() does not account for the CSS being loaded by the browser: https://stackoverflow.com/a/1324720/3633109
I am currently using JQuery UI for several UI elements on my site. Is there a way to make the highlight and error bars thinner?
I am referring to the two things found in the lower-right here.
I imagine there should be a CSS property that I can change to fix this, I just can't seem to find it.
Solution: .ui-state-highlight p { margin-top:3px; margin-bottom:3px; }
On the jQuery page there is a margin on the p tag in the content. It should conform to the content that you are inserting. Can you post the problem you are having.