Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

on error and file.open()

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    on error and file.open()

    This script is waiting for an external program to complete writing a file before it continues. If the red lines are not included onerror works for n=1, but on n=2 onerror does not fire and the error is displayed in the UI.

    Trying to read between the lines of the documentation got me to try the red lines, which solved the problem.

    Anyone have a clearer explanation than the help file? It might be useful in the wiki.

    Code:
    on error goto open_error
    for n=1 to 20
    	fp = file.open(pdfout,FILE_RO_EXCLUSIVE)	'error if writing is not finished.
    	fp.close()
    	goto pdfout_is_closed
    	open_error:
    	sleep(1)
    [COLOR="Red"]	resume next_n
    	next_n:[/COLOR]
    next n
    'if get here, file did not complete writing.
    ui_msg_box("","not closed")
    vError = .t.
    
    pdfout_is_closed:
    on error goto 0
    Bill.

    #2
    Re: on error and file.open()

    Bill,

    Upon looking at your code, it didn't work for me either. It appeared that after going to the error handling routine, the "on error goto" must be declared again to handle subsequent errors. Also, upon putting the new "on error goto" within the error routine, it would not continue the loop for n=2. Hence, the for...next loop seemed to be out of synch due to the error.

    Upon replacing the for...next loop with a while loop, it worked for me.
    Code:
    dim bClosed as L
    dim nCnt as N
    bClosed = .F.
    nCnt = 0
    
    on error goto open_error
    while .NOT. bClosed .AND. nCnt < 21
    	nCnt = nCnt + 1
    	fp = file.open(pdfout,FILE_RO_EXCLUSIVE)	'error if writing is not finished.
    	fp.close()
    	bClosed = .T.
    	
    	
    	open_error:
    	on error goto open_error
    	if .NOT. bClosed
    		sleep(1)
    	end if
    wend
    
    on error goto 0
    
    'if get here, file did not complete writing.
    if .NOT. bClosed
    	ui_msg_box("","not closed")
    	vError = .t.
    end if
    Steve

    Comment


      #3
      Re: on error and file.open()

      Interesting. Just one of the mysteries of coding I guess. Sometimes the trial and error of finding the construct that works correctly can really increase my overhead!

      Bill.

      Comment


        #4
        Re: on error and file.open()

        Have you tried moving the ON ERROR routine inside the loop so you can also have an explicit ON ERROR goto 0 inside the loop?

        Just a thought. I haven't tried it and it might not work - see below.
        Code:
         
        for n=1 to 20
           ON ERROR goto open_error
           fp = file.open(pdfout,FILE_RO_EXCLUSIVE) 'error if writing is not finished.
           ON ERROR goto 0
           fp.close()
           GOTO pdfout_is_closed
           open_error:
           sleep(1)
        next n
        'if get here, file did not complete writing.
        ui_msg_box("","not closed")
        vError = .t.
        
        pdfout_is_closed:
        on error goto 0
        I try to keep my ON ERROR calls closer together than I used to. I've run into a couple situations where I didn't do that and ended up with some other line causing an error that I never expected but the original ON ERROR was hiding the problem from me.

        I've also noticed that a lot of people will add an ON ERROR and forget to include an ON ERROR goto 0 after the line(s) in question. That wasn't the issue here but I've seen it a lot.

        Why it may or may not work:

        I did some testing awhile ago in an earlier version of A5 and discovered that the error routine automatically returns to "ON ERROR goto 0" when the original error actually does occur - but only while in the 'new' error routine. Once you "RESUME", it returns to the original error routine. In other words, if you do an

        ON ERROR goto MyErrorRoutine

        and an error does occur, then there is no need to use the ON ERROR goto 0 here:

        MyErrorRoutine:
        ON ERROR goto 0 'Not needed. The system does this automatically.
        <some code to run tests, fix things, send messages, etc.>
        RESUME NEXT

        When the "RESUME NEXT" runs, the script returns to the original ON ERROR goto MyErrorRoutine.

        Based on the above, it seems as though your routine should have switched to ON ERROR goto 0 when the error occurred then continued around the loop until it hit the 'open_error' call again.

        OR, maybe the way this "internal ON ERROR switching" is designed to work is causing the problem and doing it explicitly within the loop will solve the problem.


        And, on another subject completely, I know I'm fighting a losing battle but think this idea does have it's benefits. I really hate it when people give me applications to work on where the developer has used single characters as the loop counter in FOR loops. It can waste too much of my time trying to find out what's going on. "n" isn't usually quite as bad as "i" but it's close. For example, someone recently sent me an app to review and I had to find out what was happening. As part of that, I needed to see if/where the "i" in
        FOR i = 1 to 100
        was actually being used within the loop. It was used but only in a couple places. However, it was a huge loop and took me quite awhile to go through all the other places where the letter "i" was used. That's why you will usually see something like this in my scripts:
        FOR qx = 1 to 100
        Now when I do a search on "qx" I can be pretty sure of finding only the valid hits.

        There are very few cases where the letter "q" will be used in combination with any letter other than "u". The letter "j" also works well if you stick to using only consonants with it - you're not likely to find "jx" in many places but "ja, je, ji, jo, and ju" are very possible. If I don't use something like qx or qi, it will be a more complete variable name like line_cnt but never just a single letter. OK...

        Comment


          #5
          Re: on error and file.open()

          OR, maybe the way this "internal ON ERROR switching" is designed to work is causing the problem and doing it explicitly within the loop will solve the problem.
          Cal,

          That sounds like a reasonable explanation.

          Reading the help file again I can see where it would hint at this solution, but a more direct explanation would sure be better in the wiki. I have posted a wiki comment to this effect.

          Bill.
          Last edited by Bill Parker; 05-17-2010, 11:52 AM.

          Comment

          Working...
          X