Generating a file to hold an entire Vertical Scroll Arrangement information

Hi,
I wanted to consult about a problem I've been struggling with.

I've build an app in which the user enters some information and I have an option to display it:
Vertical Scroll Arrangement {
Horizontal Arrangement Stage1
Horizontal Arrangement Stage2
....
Horizontal Arrangement Stage8
}
Each horizontal arrangement contains a listview.
Any number of stages, 1-8, can be used (I'll display only those filled by the user).
The listviews can be in any length (1-100 for example).
This displays well on the screen. (emphasize: this VSA can be in any length, 1 to several screen's-height)

I want to create a pdf or other suggested file format, to hold all the VSA information.
The "create pdf from layout" ext doesn't work well in this case.
It doesn't auto-generate multiple pages if the layout is longer than a single page.
Even if I use Colin ext and scroll-page-down, the generated page is from the top of the layout.
Setting visability false to some horizontal-arrangements, doesn't work, meaning the generated Pdf will just have a blank section in it.

Component2Image ext works the same as the pdf creator (always generates from the top of the layout, even with scroll, and displays blank for non-visable elements)

Using Taifun screen capture ext, together with scroll-page-down works ok but:

  1. It generates several jpg files, vs. a single pdf file.
  2. Some information will appear twice, in 2 different jpgs (the last 2 jpg), because the VSA length isn't a round multiplication of the screen size.

So, is there something I'm missing?
Any suggested solution? Extension? Workaround?

Thanks in advance for your time,
Maor.

If you are using KIO4_PDF, have you tried adding pages, one for each of your horizontal arrangements inside your VSA? This is how I understand the extension should work?

The problem is that I can't know in advance which stage(s) will be active, and especially, what will be the length of the listviews inside the horizontal arrangements.

I want to create full & aesthetic pages. i.e. not having a page with just a few lines at its top and the rest empty.

You should be able to identify which arrangements are in use and get their sizes in order to set them at pdf creation time?

That said, this is starting to sound like it might work better in an html/css framework environment....

Since the pdf-create ext receives a single layout arrangement as an input, I still don't see a way, maybe i'm missing your point...
consider the following (examples) possible cases:

  1. Stages 1-3 are enabled and their length fits a single page.
  2. Stages 1-3 are enabled: Stages 1-2 occupy a full page, and Stage 3 should be on page 2.
  3. Stages 1-3 are enabled: Stages 1 occupy a full page, and Stage 2-3 should be on page 2.
  4. Stages 1-3 are enabled, and each of them occupy a full page.

I'm a newbie...what do you mean by "html/css framework environment"?
If this can solve my problem, could you please elaborate?
Does it require coding? Internet access? Extension?

Thanks!

Perhaps this explains:
image
You make a page from each horizontal arrangement inside your VSA

The PDF extension should make pages as long as the content, therefore as long as you keep your widths the same things should look OK

to use a local (on device) web page put together with html and css from the data on your VSA. A lot of work.

Each AddPage10 receives a single layout arrangement.
Your suggestion makes a static allocation of a page-per-stage...that's not what I wanted.
This would result in a lot of blank spaces on each page, since each Stage-HA doesn't usually occupy a full page. (See the different paging examples I've given above)

If I could somehow give the AddPage10 a dynamically created layout, then I could do some logic that adds the Stages length...
But the AddPage can't receive a "join" (like text) of HA: (for example)
AddPage10.layout = join("HA1", "HA2")

Thanks

I think the dynamic component extension (yusufcihan) might help.
I'll start examining it.

Hi,
I've managed to solve the problem using the dynamic component extension.
Should I post it for others? Should the post be closed? How?

Thanks,
Eran.

Yes, please show your blocks/screenshots of how you did this, it will certainly help others.

Hi,

This is my solution and how to test it:

  1. Open an application (I'm only testing these sort of app on the mobile phone, installing the apk).
  2. Fill the "List Len" TextBox with 15.
  3. Click on "Init Lists". You can see 4 ListViews in 4 HA, each 15 items long, all inside a VSA. The total height is bigger than a single screen.
  4. Click on "Create PDF" -> a pdf file is generated in the apps directory (.../android/data/..Dynamic_pdf_pages/files)
    The app closes. (I'll explain why later)
  5. You can see each HA was assigned to a different page.

Repeat steps 1-5, but enter "8" in the "List Len" TextBox.
You can see in the generated pdf, that HA1 & 2 were assigned to page1, and HW3 & 4 were assigned to page2.

Comments:

  1. This solution uses 2 great extensions:
    "Layout 2 PDF" - by Juan Antonio
    "Dynamic component" - by yusufcihan

  2. Due to some problem with the ListView, they don't show fully if their height is set to automatic (meaning, you have to scroll them to see all elements).
    As a workaround, i'm setting their height manually in "SetListsData".
    If someone have a better understanding of this, please help.

  3. After each HA is "Moved" to the dynamically created VA, they are not usable any more. this is why I've closed the app after the pdf generation.
    In a real app, I recommend performing all this in a dedicated screen, and close the screen after the pdf generation.
    This way, when the screen is opened again, the original layout will be restored.

  4. I had to use a Clock.
    Otherwise, the AddPage10 crashes on error "Height and Width must be >0".
    I assume this is because of the AI events handling/order...

Thanks,
Eran.
Dynamic_pdf_pages.aia (48.1 KB)

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.