The problem is the folowing:
I have to create a panel in Vaadin that has undefined heigth, but there is also a constraint that it should expand only til it reaches a maximum size (heigth).
Does anyone know a solution for this?
It is not yet implemented yet as a built-in feature in Vaadin, see:
http://dev.vaadin.com/ticket/6137
What can be done instead?
The only approach I can think of that may be worth trying - and I've no idea if it'll work - is to try and use a containing CSSLayout, and use max-height: in the CSS to create a maximum size for the panel.
Related
In order to refresh a part of the grid, i.e., when font or alignment changes, I was using the following approach:
wxRect rect1=CellToRect(TopLeft);
wxRect rect2=CellToRect(BottomRight);
wxRect r(rect1.GetTopLeft(), rect2.GetBottomRight());
RefreshRect(r);
This was refreshing only a part of the intended block and was not working correctly.
From the suggestions of intellisense I came across RefreshBlock function and it works correctly. I searched the docs and have not found any information on it. I wonder if it is not recommended to use RefreshBlock for some reason? What does RefreshBlock do, does it refresh a block (as the name suggests) or is it equivalent to Refresh?
I am using wxWidgets 3.2 on Win10.
Thanks in advance.
The function RefreshBlock() is indeed the best way to do what you want and it was only undocumented by mistake, i.e. we simply forgot to do it. I've added documentation for it only now, so it will only get included in 3.2.1, but you can still use it in your code, the function itself is available since 3.1.3.
It seems from the source code that, depending on the location of its parameters, RefreshBlock refreshes any of the following:
corner grid
frozen cols grid
frozen rows grid
main grid
Since the area I wanted to refresh was on the main grid the following approach works (the idea is similar to RefreshBlock's approach):
auto GridWnd = CellToGridWindow(TL);
wxRect rect = BlockToDeviceRect(TL, BR, GridWnd);
GetGridWindow()->RefreshRect(rect);
Now everything is refreshed correctly.
Notes:
If only RefreshRect(rect) is called, things will NOT work as expected.
Little experiment showed that BlockToDeviceRect(TL, BR) also works, therefore eliminating the need for auto GridWnd = CellToGridWindow(TL);
How can i solve this situation?
Assuming you are using Apache Isis 1.17.0, take a look at
wicket/wicket/resource/org.apache.isis.viewer.wicket.ui.pages.SidebarCssResourceReference/simple-sidebar-ver-1582544091730.css
and try to modify values for padding / margin. Eventually you need to override settings in application.css; sometimes you may need to use '!important'
If you are using Chrome, press <Ctrl>-<Shift>-C and select the date-time widget.
If you can provide sample code, I could take a closer look.
Is there an example of the resize function for dropzone.js? I don't really understand how it works, it says:
"Resize is the function that gets called to create the resize information. It gets the file as first parameter and must return an object with srcX, srcY, srcWidth and srcHeight and the same for trg*. Those values are going to be used by ctx.drawImage()."
But I don't really get how to use it. So far I'm resizing the images on server-side, but I'd like to do it client-side and I think this might help. Any other solutions using dropzone.js if not this one?
I believe the built-in resize function in dropzoneJS is what is used to create the thumbnail, not resize the photo client-side, per se. There might be some way you could leverage it by setting the thumbnail dimensions to what you want to save to the server, and overwriting the file being saved with the thumbnail, but I'd have to hack about for a spell to offer you any code suggestions for that.
I want use Gridster for my web site, but i need to add lot of widgets with "add_widget" command. I do a test and i think there is a problem with "add_widget" function : grid is more and more slow and there are memory leak.
You can see that in this video : grister problem video
However, as you can see on the video, if i add widget at beginning (not with add_widget function) there is no problem. Can you help me ? Something wrong with my code ?
Thanks in advance !
In my own experience, the main culprit was using the autogenerate_stylesheet setting. The problem is that it regenerates the css on every call to add_widget(), and this just absolutely kills browsers. Additionally, gridster has/had a bug where stylesheets get duplicated, filling the <head> with tons of duplicate style rules, making it tough on the browser(this bug was supposedly fixed, but my experience was that the fix only worked in specific scenarios, definitely not in mine).
When I used gridster, my widgets were always the same size. So, in my case, I was able to generate the stylesheet once, never needing to regenerate it.
I don't think its part of the public api, but you can just call generate_stylesheet() method once manually.
var gridster = $(".gridster ul").gridster({
autogenerate_stylesheet: false,
widget_base_dimensions: [140, 140],
//other options...
}).data('gridster');
gridster.generate_stylesheet({rows: 30; cols: 8});
//freely call gridster.add_widget(...); as many times as you like
Since you're only going to generate the stylesheet once, you need to make sure gridster will generate style rules for enough rows and columns to accommodate all your widgets, otherwise once you exceed the range, you'll experience broken layouts. Just supply an upper bound on rows and cols when calling generate_stylesheet(opts). If you don't, it seems like it defaults to whatever value your gridster instance is using for max_rows and max_cols.
The nice thing is by manually generating the stylesheet, is that you completely avoid the duplicate style bug too.
The exponential slowdown will be gone. Happy gridstering.
I know I'm a bit late on this but I had the same problem and none of the above solutions worked.
However, I found that I was generating the size and coordinates of the widgets as a string rather than an integer on the back-end.
By making sure they were integers I managed to speed things up loads.
The best way to fix it, is not to disable the autogenerated stylesheet, but to edit the fn.generate_stylesheet function in jquery.gridster.js
At the end of the function, just before these lines:
return this.add_style_tag(styles);
};
add this line:
this.remove_style_tags();
The final result would look like this:
this.remove_style_tags();
return this.add_style_tag(styles);
};
With this, each time a stylesheet is generated, the previous one is removed, so there no duplication problem!
I'm sure you've all seen this error before in your Titanium mobile projects. I've been getting it in an app I'm working on. It is usually thrown by the same type of operation, but not all the time and not in the same place. I'm wondering if anyone has found a solution to this issue yet.
The error is usually generated when I am iterating through an array of objects, and using that data to create views. Each new view is below its previous sibling, so the new view's top property looks something like this:
top = (from_top + old_view.height + 10);
As you can see I'm using the view.height property to figure out my top property, and I assume this is part of the problem. Anyone had any luck with this, or are you using a work around to avoid using a view's height property in addition?
(This is also posted on the Appcelerator Q&A site)
Why don't you use layout: 'vertical' instead of manually specifying the heights? It isn't in the docs at the moment, but as of 1.5 you can specify layout: 'vertical' on windows and scrollviews, possibly on views as well. Works on both iOS and Android.