• Thanks for your explanation, I didn't know this *arg, but, really, what do I know?
    Surely, not a lot 😭

  • I'm almost sure the problem comes from several wait_modal active together...

  • @mikael , it was just really to abstract the sections and the field creation for the params to the sections param to form_dialog. The extra part I didn't get to yet, was persistence. I think in reality most forms require persistence. Sure not all, but a lot. But it turns out this has been on @omz's radar anyway. I knew this before i started. So what i have tried to do will be defunct. I thought would be fun to try.

    I also think about another buzz concept, cards. At least, i see quite a few articles about a card concept in web pages. For me the idea of cards is not new. I am very old. HyperCard/SuperCard had this concept more than 20 years ago. A project was a stack of cards.
    I can see how cards in Pythonista could be very powerful. Cards is just an idea/concept. It's just a view of information and maybe its interactive or static. Then you have a stack of cards that are somehow related. This could be menu items for a restaurant or a bookings for a hotel for a day for example.
    Sorry, i know this seems to go of track. But in my mind it doesn't. @omz created a module for dialogs, to aid in the capturing/displaying of infomation.
    If I was a super Python programmer and super software framework architect, I would create a stack/card framework for Pythonista. But alas I am neither :(

    But a dialog in my mind is just a card displayed synchronously. Ok, sorry, I went past your few sentences. Maybe I didn't articulate my meaning so well. But i see it very cleaarly in my head at least. I have Had quite a few whiskeys already today, It does not make me crazy, but it brings out my passionate side :)

  • @enceladus , thanks for taking the time to explain. The defaults look at lot better the way you have done them (I think I seen the way I used in stackflow one time and have used that way, goes to show you should look at multiple sources). I understand your dict attr del, I just question @omz reasoning behind this approach. Not to be a smart ass. Just to learn. I do all sort of weird things at times (well all the time). It just really points out to me how important it is to think about inferences/rules made with Params. Look, maybe what @omz has done is actually very Pythonetic, I am certainly in no position to correct him.
    Anyway, thanks again. I am just playing with this wrapper around dialogs.form_dialog. I am going to try to add some persistence to it using shelve I think. Sure I will run into more troubles, so I will be back :)

  • I agree, it was just a quick sample.
    Personnally, I often write my own dialog with images, map view, etc...

  • is this inside a button action perhaps?

    You cannot put a blocking function inside a button action, or other methods that are called on the ui thread. The calls to the form need to be called as @ui.in_background if that is the case.

    There may be an issue which I have noticed recently when dealing with for examples the photos picker, that presenting a view while another is closing might lead to issues. yOu might try adding a time.sleep() after wait_modal, since this implies you have another view which is getting closed right before this chunk executes.

    It might be helpful to see the entire method, or a complete standalone example that shows the issue.

  • When you look at the source code of the dialogs module, you'll see that the text_dialog() function is actually very simple, and you could make your own version of it like this:

    import ui import os from dialogs import _TextDialogController def my_text_dialog(title='', text='', font=('<system>', 16), autocorrection=None, autocapitalization=ui.AUTOCAPITALIZE_SENTENCES, spellchecking=None, done_button_title='Done', selected_range=None): c = _TextDialogController(title=title, text=text, font=font, autocorrection=autocorrection, autocapitalization=autocapitalization, spellchecking=spellchecking, done_button_title=done_button_title) if selected_range is not None: c.view.selected_range = selected_range c.view.present('sheet') c.view.begin_editing() c.view.wait_modal() return c.text filename = 'myfile.txt' base_name, extension = os.path.splitext(filename) my_text_dialog('Test', filename, selected_range=(0, len(base_name)))

    This is mostly the same code as the original text_dialog(), just with an additional selected_range parameter.

  • @omz , ok great. As I say, for me the power lies in the fact it's in the app. I know it's easy to roll your own. But the distribution is not easy

  • Dialogs is intentionally minimal, with quick elements for short projects. That's great for quickly adding a bare-bones UI to something, but it means that for real control you need to use UI.

  • Thanks that works a treat

  • @cvp , sorry I did not get back to you. I have been inundated with visitors. I would not have that been that much help anyway, was so -long ago. But great you solved it.

  • @Tizzy, just copied some code to create a zip file in the root dir. Just modified it to zip the documentation folder. I opened up the zip in ZipExtractor on iOS, it appears all correct.
    Maybe useful to you...but read through it first before running it

    The zip file created on my ipad was 145.3mb

    # coding: utf-8 import os import zipfile # copied from stackflow # http://stackoverflow.com/questions/1855095/how-to-create-a-zip-archive-of-a-directory def zipdir(path, ziph): # ziph is zipfile handle for root, dirs, files in os.walk(path): for file in files: ziph.write(os.path.join(root, file)) if __name__ == '__main__': documents_path = os.path.expanduser('~/Documents') zip_file = os.path.join(documents_path , 'web_help_file_docs.zip') documentation_path = os.path.join(os.path.split(os.__file__)[0], '''../../../Documentation/''' ) print 'Starting Zip....' zipf = zipfile.ZipFile(zip_file, 'w') zipdir(documentation_path, zipf) zipf.close() print 'Zip completed'
  • Thanks! I think I wouldn't have noticed this myself because a German date picker looks pretty normal to me...

    The reason is a workaround for a bug in the iOS simulator – I'm faking a German locale because for some reason, the keyboard language can't be changed otherwise. This obviously should never have been in the version that's built for actual devices...

  • The dialogs module is so so convenient when wanting to display and interact with simple data.

    And since it's pure python (thanks @JonB for the tip) it's so easy to tinker with.

    (The ui module is way too flexible for most of my projects - so I really like the dialogs module - thanks @omz !!)

  • @omz That was it, thanks. You could tell it's been a while!

Internal error.

Oops! Looks like something went wrong!