SWT Composite maximum size - size

I have a ScrolledComposite, the contents of which are being truncated. I have Googled and am aware that it is a known issue on Windows.
The only suggested workaround I can find is to use the canvas.scroll functionality.
Given the age of the issue, I was wondering if there is a nicer workaround?
Thank you!
(EDIT: At the time of writing, the link was: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet48.java?view=markup&content-type=text%2Fvnd.viewcvs-markup&revision=HEAD)

(the link you posted gave a 400 Error)
Not sure if my issue was the same, but I ran into a truncation issue with ScrolledComposite as well. The problem was that when I resized the Composite to be scrolled and the Scrollbar became visible, the controls didn't account for the space taken up by the scrollbar. To solve this, I added a kind-of recursive bit of code to my Resize listener on the scrolled composite:
After you have set the size of your content composite, check if the scrolledComposite's scrollbar (getVerticalBar() for example) has just become visible. If so, send a new Resize event to your listener. Here's a snippet from my code...
public void handleEvent(Event event)
{
int newWidth = scrolledComposite.getSize().x;
boolean hasScroll = false;
ScrollBar scrollBar = scrolledComposite.getVerticalBar();
if (scrollBar.isVisible())
{
hasScroll = true;
newWidth -= scrolledComposite.getVerticalBar().getSize().x;
}
newWidth -= 8;
Point size = contentComposite.computeSize(newWidth, SWT.DEFAULT);
contentComposite.setSize(size);
int scroll_multiplier = size.y / 50;
scrollBar.setIncrement(scroll_multiplier);
/**
* If the scroll bar became visible because of the resize, then
* we actually need to resize it again, because of the scroll
* bar taking up some extra space.
*/
if (scrollBar.isVisible() && !hasScroll)
{
scrolledComposite.notifyListeners(SWT.Resize, null);
}
}
Hope this helps!
Edit: wow I didn't notice the date of the OP. Hope this ends up helping someone either way...

Related

how to verify view is scrollable in mobile application (Automation)

Anyone knows automation script to verify a view (homePage/Browse) is scrollable or not. i can use ScrollTo(id) which is at the bottom of the page. But it is not a correct method to do, as test case passes if that element present in 1st page
Basically You cannot. You could try to cast the view to ScrollView class however any custom view can implement scroll.
Get the coordinates of any particular element like button etc unique element.
Swipe using driver.swipe() to 100 or more pixels.
And get the coordinates of that element again and check whether x or y coordinates changed or not.
This will let you know whether it is a single page application or more to scroll.
Basically there is no API to check the view is scrollable or not but if you still require this then you can do work around
#Test
public void testVerticalScroll()
{
//Try to Scroll till the 15th row
driver.scrollTo("List item:15");
//Assert that the 1st row is not visible.
Assert.assertFalse( driver.findElement(By.name("List item:01")).isDiaplyes())
//Assert that the 15th row is not visible.
Assert.assertTrue( driver.findElement(By.name("List item:15")).isDiaplyes())
}
You can consider the last visible element as "YourText" But this is
just a workaround that needs to be customized for each page.
Here we are using swipe until we find the element. In this case, the last visible element indicates the margin of the page.
Dimension dimensions = driver.manage().window().getSize();
Double screenHeightStart = dimensions.getHeight() * 0.5;
int scrollStart = screenHeightStart.intValue();
System.out.println("s="+scrollStart);
Double screenHeightEnd = dimensions.getHeight() * 0.2;
int scrollEnd = screenHeightEnd.intValue();
for (int i = 0; i < dimensions.getHeight(); i++) {
driver.swipe(0,scrollStart,0,scrollEnd,2000);
if (driver.findElement(By.name("YourText")).size()>0)
exit;
}
driver.findElement(By.name("YourText")).click();
There is a way to check it. You have to find a layer that you will target for example:
MobileElement scrollableLayer= driver.findElementById("elementID");
Then you will extract attribute value "scrollable" of that element like this:
String scrollableState = scrollableLayer.getAttribute("scrollable");
And then you can check if the String value is true or false.
if (scrollableState.equals("true")){System.out.println("it's scrolable"); }else{System.out.println("it's not scrolable");}
Or you can do whatever you want with it :)

Setting Comments in Excel (with apache poi)

I'm trying to set cell comments to a set of cells, and for the ones that are on the right of the page, the comments have the proper size, but for the others that are on a previous column of the page, their size begin to descrease with no appearent explanation (for me).
Screenshots of the situation:
Comment with the correct size
http://prntscr.com/7ez65x
Starting to became narrower
http://prntscr.com/7ez6bm
And for the ones that are on previous columns, the comments don't have width at all... like they have collapsed on themselves.
The code that i'm using to generate the comments is:
protected void setCellComment(Cell cell, String message)
{
Drawing drawing = cell.getSheet().createDrawingPatriarch();
CreationHelper factory = cell.getSheet().getWorkbook().getCreationHelper();
ClientAnchor anchor = factory.createClientAnchor();
int width = 3;
int height = 2;
anchor.setCol1(cell.getColumnIndex());
anchor.setCol2(cell.getColumnIndex() + width);
anchor.setRow1(cell.getRowIndex());
anchor.setRow2(cell.getRowIndex() + height);
anchor.setDx1(100);
anchor.setDx2(100);
anchor.setDy1(100);
anchor.setDy2(100);
Comment comment = drawing.createCellComment(anchor);
RichTextString str = factory.createRichTextString(message);
comment.setString(str);
cell.setCellComment(comment);
}
Please Help!
Thanks a lot
I solved the problem removing the freezing panes that the sheet had. Probably there is a bug with the combination between freezing panes and comments.

Resizing desktop application with ligdx issues

I'm trying to make an app using libgdx. When I first launch it on my desktop, my map print well. But if I resize the window, the map is no longer completely in the screen.
But if I change the size on the beginning, the map print well. So there might be an issue with my resizing function.
In my GameScreen class I've got :
public void resize(int width, int height)
{
renderer.setSize(width, height);
}
And my renderer got this :
public void setSize (int w, int h)
{
ppuX = (float)w / (float)world.getWidth();
ppuY = (float)h / (float)world.getHeight();
}
For example, if I reduce my window, the map is too small for the window. If I extend it, the map doesn't in it.
If you have a fixed viewport, which is the case most of the time. You don't need to do anything in your resize method. The camera will fill the window to draw everything even if you resize it at runtime.
I, myself, never put anything on resize.

ScrollViewer and SetHorizontalOffset

I use scrollviewer in my windows store application, but after calling SetHorizontalOffset function some times scrollviewer doesn't change horizontal scrolling. The same thing with vertical scrolling. Does anybody know how to work with it? May be scrollviewer scroll only for visibility for offset (I mean that if it's see that user can see offset its doesn't scroll at all)
It appears the ScrollViewer's offset lags by one frame.
If the below code is run every frame, diffPrevDesiredActual is always 0. That is to say, the value provided by ChangeView does not take affect immediately.
...
var scrollPosition = /*some new value*/;
MyScrollViewer.ChangeView(null, scrollPosition, null, true);
var current = MyScrollViewer.VerticalOffset;
var diffDesiredActual = scrollPosition - current;
var diffPrevDesiredActual = previous - current;
previous = scrollPosition;
...
private double previous;
If nothing on your screen is animating when you change the scroll offset, then it is possible the ScrollViewer won't show the new value until something triggers the draw of a new frame. To test this hypothesis, try adding an infinite animation (eg ProgressRing) to ensure frames are constantly being drawn.

while I scroll between the layout it takes too long to be able to scroll between the gallerie's pictures. Is there any way to reduce this time?

this is my first question here, though I've being reading this forum for quite a while. Most of the answers to my doubts are from here :)
Getting back on topic. I'm developing an Android application. I'm drawing a dynamic layout that are basically Galleries, inside a LinearLayout, inside a ScrollView, inside a RelativeLayout. The ScrollView is a must, because I'm drawing a dynamic amount of galleries that most probably will not fit on the screen.
When I scroll inside the layout, I have to wait 3/4 seconds until the ScrollView "deactivates" to be able to scroll inside the galleries. What I want to do is to reduce this time to a minimum. Preferably I would like to be able to scroll inside the galleries as soon as I lift my finger from the screen, though anything lower than 2 seconds would be great as well.
I've being googling around for a solution but all I could find until now where layout tutorials that didn't tackle this particular issue. I was hoping someone here knows if this is possible and if so to give me some hints on how to do so.
I would prefer not to do my own ScrollView to solve this. But if that is the only way I would appreciate some help because I'm not really sure how would I solve this issue by doing that.
this is my layout:
public class PicturesL extends Activity implements OnClickListener,
OnItemClickListener, OnItemLongClickListener {
private ArrayList<ImageView> imageView = new ArrayList<ImageView>();
private StringBuilder PicsDate = new StringBuilder();
private CaWaApplication application;
private long ListID;
private ArrayList<Gallery> gallery = new ArrayList<Gallery>();
private ArrayList<Bitmap> Thumbails = new ArrayList<Bitmap>();
private String idioma;
private ArrayList<Long> Days = new ArrayList<Long>();
private long oldDay;
private long oldThumbsLoaded;
private ArrayList<Long> ThumbailsDays = new ArrayList<Long>();
private ArrayList<ArrayList<Long>> IDs = new ArrayList<ArrayList<Long>>();
#Override
public void onCreate(Bundle savedInstancedState) {
super.onCreate(savedInstancedState);
RelativeLayout layout = new RelativeLayout(this);
ScrollView scroll = new ScrollView(this);
LinearLayout realLayout = new LinearLayout(this);
ArrayList<TextView> texts = new ArrayList<TextView>();
Button TakePic = new Button(this);
idioma = com.mateloft.cawa.prefs.getLang(this);
if (idioma.equals("en")) {
TakePic.setText("Take Picture");
} else if (idioma.equals("es")) {
TakePic.setText("Sacar Foto");
}
RelativeLayout.LayoutParams scrollLP = new RelativeLayout.LayoutParams(RelativeLayout.LayoutParams.FILL_PARENT,
RelativeLayout.LayoutParams.FILL_PARENT);
layout.addView(scroll, scrollLP);
realLayout.setOrientation(LinearLayout.VERTICAL);
realLayout.setLayoutParams(new LayoutParams(LayoutParams.FILL_PARENT,
LayoutParams.FILL_PARENT));
scroll.addView(realLayout);
TakePic.setId(67);
TakePic.setOnClickListener(this);
application = (CaWaApplication) getApplication();
ListID = getIntent().getExtras().getLong("listid");
getAllThumbailsOfID();
LinearLayout.LayoutParams TakeLP = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.WRAP_CONTENT,
LinearLayout.LayoutParams.WRAP_CONTENT);
realLayout.addView(TakePic);
oldThumbsLoaded = 0;
int galler = 100;
for (int z = 0; z < Days.size(); z++) {
ThumbailsManager croppedThumbs = new ThumbailsManager(Thumbails,
oldThumbsLoaded,
ThumbailsDays.get(z));
oldThumbsLoaded = ThumbailsDays.get(z);
texts.add(new TextView(this));
texts.get(z).setText("Day " + Days.get(z).toString());
gallery.add(new Gallery(this));
gallery.get(z).setAdapter(new ImageAdapter(this, croppedThumbs.getGallery(), 250, 175, true,
ListID));
gallery.get(z).setOnItemClickListener(this);
gallery.get(z).setOnItemLongClickListener(this);
gallery.get(z).setId(galler);
galler++;
realLayout.addView(texts.get(z));
realLayout.addView(gallery.get(z));
}
Log.d("PicturesL", "ListID: " + ListID);
setContentView(layout);
}
private void getAllThumbailsOfID() {
ArrayList<ModelPics> Pictures = new ArrayList<ModelPics>();
ArrayList<String> ThumbailsPath = new ArrayList<String>();
Pictures = application.dataManager.selectAllPics();
long thumbpathloaded = 0;
int currentID = 0;
for (int x = 0; x < Pictures.size(); x++) {
if (Pictures.get(x).walkname == ListID) {
if (Days.size() == 0) { Days.add(Pictures.get(x).day); oldDay = Pictures.get(x).day;
IDs.add(new ArrayList<Long>()); currentID = 0; }
if (oldDay != Pictures.get(x).day) {
oldDay = Pictures.get(x).day;
ThumbailsDays.add(thumbpathloaded);
Days.add(Pictures.get(x).day);
IDs.add(new ArrayList<Long>());
currentID++;
}
StringBuilder tpath = new StringBuilder();
tpath.append(Pictures.get(x).path.substring(0,
Pictures.get(x).path.length() - 4));
tpath.append("-t.jpg");
IDs.get(currentID).add(Pictures.get(x).id);
ThumbailsPath.add(tpath.toString());
thumbpathloaded++;
if (x == Pictures.size() - 1) {
Log.d("PicturesL", "El ultimo de los arrays, tamaƱo: " + Days.size());
ThumbailsDays.add(thumbpathloaded);
}
}
}
for (int y = 0; y < ThumbailsPath.size(); y++) {
Thumbails.add(BitmapFactory.decodeFile(ThumbailsPath.get(y)));
}
}
I had a memory leak on another activity when screen orientation changed that was making it slower, now it is working better. The scroller is not locking up. But sometimes, when it stops scrolling, it takes a few seconds (2/3) to disable itself. I just want it to be a little more dynamic, is there any way to override the listener and make it stop scrolling ON_ACTION_UP or something like that?
I don't want to use the listview because I want to have each gallery separated by other views, now I just have text, but I will probably separate them with images with a different size than the galleries.
I'm not really sure if this is possible with a listadapter and a listview, I assumed that a view can only handle only one type of object, so I'm using a scrollview of a layout, if I'm wrong please correct me :)
Also this activity works as a preview or selecting the pictures you want to view in full size and manage their values. So its working only with thumbnails. Each one weights 40 kb. Guessing that is very unlikely that a user gets more than 1000~1500 pictures in this view, i thought that the activity wouldn't use more than 40~50 mb of ram in this case, adding 10 more if I open the fullsized view. So I guessed as well most devices are able to display this view in full size. If it doesn't work on low-end devices my plan was to add an option in the app preferences to let user chop this view according to some database values.
And a last reason is that during most of this activity "life-cycle" (the app has pics that are relevant to the view, when it ends the value that selects which pictures are displayed has to change and no more pictures are added inside this instance of this activity); the view will be unpopulated, so most of the time showing everything wont cost much, just at the end of its cycle
That was more or less what I thought at the time i created this layout. I'm open to any sort of suggestion or opinion, I just created this layout a few days ago and I'm trying to see if it can work right, because it suits my app needs. Though if there is a better way i would love to hear it
PD: I've being toying to see how much it can actually draw. I managed to draw 530 galleries with 600 thumbnails on the same layout, the app is using 42 mb, and I don't have access to more memory to start my full sized view afterwards :( .I tried to do the same with 1000 but it throws OutOfMemory error, bitmap size exceeds vm budget. Is there any way to make more memory availeable on high-end devices? Or should I try to figure out a way not to draw everything at once? Would the listview work for more than one type of object?
Thanks
Mateo
Why not make your galleries items of a listview? That way you won't have to inflate all of them immediately and can the advantage of the listview recyling mechanism. Some of the slowness you are seeing might be coming from very heavy memory usage. Galleries aren't exactly light widgets so you might be seeing pauses from heavy GC activity once you stop scrolling. ListView with an adapter would also allow you to lazily bind the Galleries to the list, such that during a fling you aren't doing the expensive binding of the galleries.