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

v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

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

    #16
    Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

    Originally posted by JetLi View Post
    Just a problem of closing the code editor, if you opened it with a blank code then close , it will pop up the error and you have no way to close it until you press ctrl + del and end task alpha five. please see attached file
    I can't reproduce your problem on this machine..... I'd try a full re-install of the most recent a5 version.
    (Also, what version of windows ~ Win2k, or newer with the old shell?)
    Robert T. ~ "I enjoy manipulating data... just not my data."
    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

    Comment


      #17
      Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

      I was testing on a Win7 64bit machine - I will take a look on a couple more machines.

      Comment


        #18
        Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

        Originally posted by JetLi View Post
        Just a problem of closing the code editor, if you opened it with a blank code then close , it will pop up the error and you have no way to close it until you press ctrl + del and end task alpha five. please see attached file
        This thread is an attempt to submit bigs/issues in a specific manner and I think anyone should attempt to follow Roberts first post when adding an issue to the thread. By doing so it will not get lost and perhaps get the attention of Alpha employees (as his posts already have). Just a suggestion for trying to keep what appears to be a good start going in the right direction. SO please read the first post and try to follow the directions. Otherwise this thread will turn into a UN-followable mess.

        Thanks Robert for the effort!
        Bill Griffin
        Parkell, Inc

        Comment


          #19
          Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

          TABLE: FIELD RULES [default values prohibit saving/advancing records]
          v.11 (build 2669) ~05/09/2012
          History: Issue existed in prior versions & builds. I believe I reported this several years ago.
          Status: RESUBMITTED
          Alpha's Response: ~Alpha considers this to be normal & expected behavior.

          In any give DBF table (possibly SQL too), at least one field must have a value manually assigned, [which can not the same as the default value.] This means that a table with all default values set and accepted can not be saved. (Poblem exists even if one of the fields is auto-increment!) ~ Apparently, fields assigned with default values via table rules do not trigger a5 to acknowledge that data has been entered into a new record, and that the new record can be saved.
          • Make a simple .dbf table with 3 character type fields. (first field set to auto-increment with a default of "0000001") The other two fields can be any character fields.
          • Set these two other fields to populate with simple values. [ie. "RESET" and "n/a"]
          • Open the default browse and try to enter a record..... YOU CAN'T SAVE IT.
            (You can't hit enter, or use the save button in the a5 toolbar to save/advance to the next record.)

          NOTE: Assigning default values to fields [as opposed to having them automatically populated by defaults] should have no impact on being able to save a record. ~ Also: This problem occurs regardless of whether any of the fields are set to "required."
          Last edited by SNusa; 05-14-2012, 10:24 AM.
          Robert T. ~ "I enjoy manipulating data... just not my data."
          It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
          RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

          Comment


            #20
            Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

            BROWSE: VERTICAL SCROLL BAR [does not size properly with over 100 records]
            v.11 (build 2669) ~05/09/2012
            History: Ongoing & longtime outstanding issue I believe.
            Status: NOT SUBMITTED

            With more than 100 records, the vertical scroll bar does not size properly/proportionally, relative to the quantity of the records displayed. [until you scroll down to the end, then it re-sizes appropriately] Also, records count displayed does not properly reflect total amounts in scroll when browse is configured to show record count. (Always displays x out of 100, with 100 being the [incorrectly displayed] top limit even when you're showing record# 250)..... NOTE: I"m seeing this with .dbf tables. ~To reproduce this, open a default browse on a ~150+ record .dbf table.

            Here's the problem in video/simple form: http://screencast.com/t/QTNUgHBh
            This simple table (default browse view) has nearly 300 records, but you'd never know it based on the scroll bar. (or the info presented in the bubble help)
            Take notice of the count displayed, the size of the bar, and what happens when you get near the bottom of the 1'st 100 records.

            Note: The indexes were just rebuilt, and are fine.....

            Also: Another "loosely related: issue: Bubble help doesn't completely show. In some display selections, the width of the record position info bubble help display field is way too narrow. [virtually useless for most of the display options] This may be a screen thing, as I am presently have monitor to 1920x1200 resolution, and are using 125% sized font display. The other problem here is, regardless of how many records are in the table, bubble help only reports x out of 100.....
            Problems like this never seem to go away. They always seem to "mysteriously reappear somehow".... (again and again) While bugs like this may not be critical ones, they most certainly must hinder Alpha Software's "posture" in the industry. This is reminiscent of taking delivery of my first 2 Mustang GT's back in the 80's. First one: All the screws holding the inside panels fell out on the way home from the dealership. The second one (a few years later) severely overheated, and steam began blowing all over the windshield [less than 1/4 mile down the road] on Rt.1, because someone never connected the coolant/heating hoses at/behind the firewall...... Poor QC, I'll say no more. ~Aaarrgggghhhhh....

            PARTIAL WORKAROUND: Browse view settings [in a5 settings] set to show 250 only show 100 records. Setting this to 500 shows 250 records. Setting it to 1000 shows even more.... (Now I'm seeing the entire 290 records.) ~ Note: Bubble slider info still doesn't dynamically re-size properly/enough. (necessary to display many of the browse bubble help expression options) "I think we're infested."

            If I want to see scrollbar data, unless I use the following setting, I never know what to expect with regards to overall behavior:
            (And I can only display the basics, as the longer scrollbar strings are too wide to properly display in the "bubble.")
            A5.SYSTEM_MODE_SET("index_pseudo_position_cutoff","0")
            http://wiki.alphasoftware.com/How+to...cal+scroll+bar ~ Thanks Tom! (post# 21)
            Last edited by SNusa; 05-15-2012, 09:46 AM.
            Robert T. ~ "I enjoy manipulating data... just not my data."
            It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
            RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

            Comment


              #21
              Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

              Robert,
              Regarding the vertical scroll bar issue.

              It may not be completely corrected, but Alpha DID make a correction to the vertical scroll bar issue which actually severely impacted us. They created a calculation that gets done on every movement up or down the browse. This calculation rendered our browses inoperable. Many of our tables are VERY large (>100K records), and this calculation for each record passed through brought the browse display to its knees. We were advised by Selwyn to turn off the recalculation, and we are now able to use browses. Alpha worked with us to pinpoint the issue and quickly got us the fix.

              Tom

              Comment


                #22
                Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

                EDIT FIELD RULES: ERRONEOUS INCORRECT WARNING [that a5 does not have exclusive use of table to make edits]
                v.11 (build 2669) ~05/09/2012
                History: New with the introduction of the new localized [cached] help/documentation.
                Status: DOCUMENTED & SUBMITTED
                Alpha's Response: ~Confirmed & Acknowledged. Fixed in next release.

                If you're using the new help system in modeless mode using .dbf as the data store, you may experience an a5 erroneous warning that field rules, indexes and table structure can only be viewed and not edited, as a5 cannot get exclusive use of the table. [When trying to modify field rules, indexes, and table structure] (see photo near bottom)

                This type of warning notification may also lead you to think that you have somehow generated bad Xbasic code that is creating multiple instances of the same form/table open. (That's why I decided to list the bug here.)

                When this happens, here is what is causing the false warning (which you can ignore):
                You have first opened up a form, and placed it in edit mode.
                Then you launched the new localized help system. (settings set to modeless & .dbf data store)
                Instead of closing help, you chose to move it out of the way instead.
                At this point, even if you close the form (with the help window still open) alpha becomes "confused" thinking the form is still open....
                (And hence the warning that the table is still in use / in another session.)

                Now, even if you close the form (with the help window still open and out of the way) alpha incorrectly warns you that table is being used in another session. [When you try to go to Design / edit field rules / indexes / table structure from the tables tab of the control panel you will encounter the false warning.]

                Providing nothing else has access/is open & using this table, you can ignore the warning. (The warning is incorrect. You can in fact edit table rules etc.) ~Or just close the help system to get rid of the warning, begin editing the table and re-open the help.....

                Snap 2012-05-15 at 07.22.29.png
                ~Just another one of those errors which can lead to questioning "ones understanding & abilities", while providing a touch of added frustration."
                Last edited by SNusa; 05-23-2012, 09:47 PM.
                Robert T. ~ "I enjoy manipulating data... just not my data."
                It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                Comment


                  #23
                  Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

                  Originally posted by SNusa View Post
                  TABLE: FIELD RULES [default values prohibit saving/advancing records]
                  v.11 (build 2669) ~05/09/2012
                  History: Issue existed in prior versions & builds. I believe I reported this several years ago.
                  Status: RESUBMITTED
                  Alpha's Response: ~Alpha considers this to be normal & expected behavior.

                  In any give DBF table (possibly SQL too), at least one field must have a value manually assigned, [which can not the same as the default value.] This means that a table with all default values set and accepted can not be saved. (Poblem exists even if one of the fields is auto-increment!) ~ Apparently, fields assigned with default values via table rules do not trigger a5 to acknowledge that data has been entered into a new record, and that the new record can be saved.
                  • Make a simple .dbf table with 3 character type fields. (first field set to auto-increment with a default of "0000001") The other two fields can be any character fields.
                  • Set these two other fields to populate with simple values. [ie. "RESET" and "n/a"]
                  • Open the default browse and try to enter a record..... YOU CAN'T SAVE IT.
                    (You can't hit enter, or use the save button in the a5 toolbar to save/advance to the next record.)

                  NOTE: Assigning default values to fields [as opposed to having them automatically populated by defaults] should have no impact on being able to save a record. ~ Also: This problem occurs regardless of whether any of the fields are set to "required."
                  This is one that I would only want "fixed" if done very, very carefully. In fact, I'd rather is wasn't "fixed". Let me explain....

                  Today, if a user starts a new record then goes to another record (very easy in a browse; a little tougher but very doable in a form), the original "new" record will be automatically saved UNLESS no fields are edited beyond their defaults. If records with nothing but defaults are allowed to save automatically, I can guarantee that a LOT of users will end up with many "blank/default" records. If this was "fixed", I would want the "fix" to REQUIRE a manual (or xbasic) "save" action and not allow the record to save just because someone accidentally started it then moved off of it.

                  I also don't see the advantage to this. Why would you ever want a whole bunch of "default" records in your database? (OK, maybe if one of the defaults was based on some calculation that would result in different values in each record but I can't see any purpose for this right now. It would certainly be a highly unusual situation.)

                  If you really wanted to automate the creation and saving of a "default" record, you could create a script that would start the new record then edit a field that the user doesn't see. Editing that field would make it possible to save the record. You'd then have to start the new record by clicking a button (or some other xbasic action) but a lot of apps require some special action to start a new record anyway.

                  Comment


                    #24
                    Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

                    RTF FIELDS: NOT REFRESHING TO DISPLAY CORRECT CURRENT VALUE OF SHARED VARIABLE:
                    [two fields, one variable, different values displayed simultaneously on layout/form]

                    v.11 (build 2686) ~05/22/2012
                    History: Unknown.
                    Status: DOCUMENTED & SUBMITTED

                    Here's a good one for the record books: Two fields on the same form in v.11, displaying the same shared variable [initially declared & assigned at the table level], but last updated [new value assigned] via an an embedded browse OnRowChange event. (One field being a standard type in field, and the other a RTF displaying the exact same value/shared variable.)

                    I've included the example that displays different values in these two "form fields" (the different values displayed are not within the browse.) ~ This occurs until you refresh the form, (or just the RTF field) one time via the refresh() method! (or select Form-->Refresh (F5) from a5 menu) [Somehow, the RTF field remains "stuck" displaying the old value after the browse event fires, but the other type in field gets the update.] ~I didn't realize it until after the fact, but it is occurring in the "table events mini "application" I put together to watch table events firing. Scary part is, usually I get a fast response either indicating the problem is fixed, or I get the "we can't reproduce it" response [that I follow up with an example as proof."] This time around [thus far, one week later], complete silence.......

                    With my 6'th sense, I think I even know what may be happening..... When a5 updates layout data, refresh is not working "deep enough" into the form. [It's only refreshing the RTF object itself, and not properly refreshing the values withing the RTF object.]

                    See it in action here: Screen-cast of bug in action.
                    Here is the offending code proof of concept example: http://msgboard.alphasoftware.com/al...l=1#post610728

                    If you try the example, run the form, and select different records within the browse using the CUSTNAME field. You'll notice the values on the form (in red outside the browse) become out of sync. Then use Form-->Refresh (F5) from the a5 menu. Lastly, go to edit mode, and see the variables, both the exact same..... The good news is the problem is not Xbasic. It's the a5 front end.
                    Last edited by SNusa; 05-29-2012, 05:59 PM.
                    Robert T. ~ "I enjoy manipulating data... just not my data."
                    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                    Comment


                      #25
                      Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

                      "BUGGY DEBUGGER:" [Several bugs which have re-appeared after supposedly being fixed months ago.]
                      v.11 (build 2686) ~05/22/2012
                      History: Previously submitted & supposedly fixed in initial release of v11.
                      Status: DOCUMENTED & SUBMITTED

                      The first two of these "debugger bugs" were reported months ago, and supposedly fixed... (NOT)

                      First Photo:
                      • Add an Expression and the select Break on Change and you get an empty expression. (It works, but it's empty. It should show the variable being watched.)
                      • When you click on the X to try and delete it, you can't.
                      • When you click on the red dot (next to the X) to try and disable/delete, you can't.
                      • Also, the bubble help indicates you are deleting when you click on the red dot. You're actually "supposed to be" disabling it when you click on it, and it turns pink.
                      • (Exit & disable (mis-labeled) work only when defining a standard expression, ie: a=5, or vl_Cancel = .T. But the don't work when "Break on Change" is selected.
                      Related: Once the above issue occurs, the Profiling window seems to stop recording data....
                      (Not sure on this, because I may not be using it correctly.)

                      Second Photo:
                      • Even though the expressions (above) don't show, the breaks do work.
                      • BUT: The buttons don't behave as labeled:
                      • Delete doesn't delete them. ~ Doesn't do anything really (apparently the button is broken)....
                      • Disable doesn't actually disable, it simply "Ignores" one occurrence.....
                      • (Shouldn't these buttons be labeled: Close, Continue, & Delete?) ~ And then perform as expected!


                      Last Photo:
                      • The speed keys (underlined) don't work (you have to use the mouse):
                      • There should really be a third "HALT" button included right within this Error message screen....
                      • (I'd put it right above the existing two buttons, and make it double width in size. ~ And make it the default, because it will likely be used twice as frequently.)

                      ~Has anyone at Alpha actually used the debugger? The debugger's UI is horrendous! ~ Sorry, but it is what it is.

                      Almost Forgot:
                      • Why does the debugger end up "caught" in the background, while a5 is frozen all the time. (You forget it's there and think a5 has crashed.)
                      • When the debugger is awaiting input, it sould pop up over on top of all other a5 windows. [Instead of remaining hidden!]
                      • (At the very least, give the debugger an option to beep, or flash the taskbar. [and let user enable & select beep sound in settings]

                      A touch of attention to detail, and a few minor adjustments to the DEBUG GUI could completely fix all of this.
                      ~GREAT FEATURES & CAPABLE, BUT IT'S A "BUGGY DEBUGGER" THAT IS NOT USER FRIENDLY..........


                      Snap 2012-05-18 at 00.11.25.pngSnap 2012-05-18 at 00.10.51.pngSnap 2012-05-18 at 00.25.18.png


                      PS: I started this thread, and continue to post issues here because I do care! The goal is to help a5 to become a better product/tool! (Besides, a5 users [any users of any product for that matter] shouldn't resolve to merely tolerating problems like these. Doing so breeds "mediocracy", which typically [eventually] results in "epic failure.")
                      Last edited by SNusa; 05-29-2012, 05:58 PM.
                      Robert T. ~ "I enjoy manipulating data... just not my data."
                      It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                      RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                      Comment


                        #26
                        Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

                        BROWSE BUTTONS: CONFIGURING BUTTONS TO DISPLAY DYNAMIC DATA ON BROWSE CAN CORRUPT BROWSE. (Other related errors included below!)
                        ["standalone browses", created on the browse tab]
                        v.11 (Build 3147 Addins: 4060) ~ 01/2013
                        History: Unknown.
                        Status: DOCUMENTED & SUBMITTED ~ Correspondence w/ Cian leads me to believe he is "hot on these issues."
                        Looks like they are still fixing bugs [at least] in a5 v.11x desktop!

                        While creating / editing button displaying on a browse (via the browse tab) the entire browse can become corrupted so that it no longer loads properly. (I was editing the dynamic display content of a button withing the browse field when it closed the browse unexpectedly.) Now I have to start over as the browse is "ruined"..... From this point on, it will not load correctly. No known "work-around." You have to start over, and re-create the browse from scratch!

                        Double clicking the browse (in browse tab) results in a5 displaying a "Could not load that saved layout." error.... Click on OK results in the browse appearing and working as expected.) ~ And you can actually toggle between view and design modes (via the toolbar button) which is surprising. [For a long time, the view/design button on the browse toolbar was a "one way button." You could switch to view, but not back to design. To get around this, you have to close the browse and re-open it in edit mode.]~ Ironically, switching back and forth between view and design works (ONLY WITH) a corrupted browse!

                        Regarding the corrupted browse: If you however attempt to initially open the corrupted browse in design mode (from the control panel), it will open for editing, but does not look right. Most of the window (99%) is completely empty/white space. From this point on, you can click between design and view. (you still get the errors) ~ I have preserved this corrupted browse as "evidence."

                        OTHER SIGNIFICANT ASSOCIATED ISSUES:
                        Once the browse is corrupted, you can open multiple instances of the browse in design mode.

                        When you first attempt to create a button with dynamic content problems appear (with any browse, long before the browse unexpectedly becomes corrupted.):
                        While first attempting to create a new button (when you first arrive in the Edit Button" tab [after selecting/adding controls]: The expression builder selector (the "mini-buttons at field edges") that should appear next to fields within the editing window fail to appear. (for instance the "Button text" field) You have to first save the button, and then go back into the "edit button" window to have the expression builder available. ~ This in itself is not a huge deal but the following is:

                        The previews of the buttons you create does not display properly while designing them! This preview of the button is displayed differently in several places during the design process. (while creating/editing the button.) ~ Button is first displayed in the "Browse Cell Display Format Builder" window, then in the "Advanced Text Properties" window, and again in the "Edit Button" window. (in that order) ~ Some of the displays are completely illegible, full of strange characters.
                        In the end, designing a button with dynamic content necessitates a lot of "guesswork." (providing the browse does not corrupted first) ~ Because you can't see what you are going to get until you actually view the browse! And each time you repeat the process, you increase the likelihood the browse will become corrupted.

                        Forgot to mention: Sometimes, when you're creating/editing buttons (on the "Advanced Text Properties" window) the "Available Controls" list does not always populate properly. AND sometimes, when you right click on an existing browse column (to edit an existing button), the entire pre-existing button gets wiped out and disappears completely. ~ This problem just happened seconds ago while I was editing (actually looking at an existing button actually to see how I had designed it) within an entirely different database, on an embedded browse that was built on the form itself. (not in the browse tab) ~ When I went to re-edit the button, (to see how I built it) the first thing I noticed was the "Selected Controls" list no longer contained any objects. I didn't hit save, because I knew something was wrong. I selected canceled. In front of my eyes, the "buttons (in the form, on the browse) that were there (seconds ago) "disappeared without a trace!!!" ~ This has happened on other occasions too.....


                        I attached a photo of the button (appearing in the background, and with an error that popped up, which seldom happens when you "loose the button." This time an error appeared.) In any event, notice the quantity field with the functional buttons displaying in the background on the form. They are there, but there is no indication of this on the "Advanced Text Properties" window, prior to the error popping up. (Usually you don't get any error, just nothing is populated in the "Selected Controls." And when you cancel, the buttons (that were previously embedded in the browse) usually disappear on the form without trace! They didn't disappear on this one instance. But immediately afterwards, I right clicked on the quantity field, selected "Edit Display Format" (to try to view/edit them again) and noticed (once again) that the "Selected Controls" had not populated correctly. This time when I "cancelled" the buttons disappeared from the form. There is no "undo" action to fix this, and the only workaround is to restore the form to a prior version. Occasionally, I have been able to restore a form, and then somehow get back in and view/edit the buttons. I got it to work a few moments ago, but have been trying ever since without any "luck." ~ This is a disaster!

                        Snap 2013-01-10 at 13.26.42.png

                        Another "minor" issue regarding browse creation: Once you begin to create a new "stand-alone" browse, you can't change your mind. You have to at least create and save something. (The a5 gui does not allow you to cancel. You have to first save it, and then delete it from the control panel.) ~ I previously reported this twice. (maybe two years ago?)

                        I am coming to the conclusion that you should not/cannot place buttons on browse objects in v.11! (And consequently, I have finally run into a bug which is making it difficult, if not impossible to finish building an application via a5 desktop v.11x.)

                        Notes:
                        I have (recently) encountered several other errors while attempting to design browse buttons that display "dynamic data." I suspect that all of these errors (including the ones detailed above) appear to be the result of an "a5 internal delimited text issue." (And that these errors are all somehow related.)


                        Trace window info while attempting to open the corrupt browse:
                        TRACE HOOK ERRORS: (as shown in trace window)
                        ______________________________________________________________
                        ControlPanel.OnActivate : Cancel selected()
                        addin.variables().a5_error_show(Could not load that saved layout) : Property not found
                        *INTERMEDIATE_00000051.a5_error_show method not found.
                        ControlPanel.DeActivate : Cancel selected()
                        Browse.Activate : Cancel selected()
                        Browse.DeActivate : Cancel selected()
                        Last edited by SNusa; 01-10-2013, 10:25 PM.
                        Robert T. ~ "I enjoy manipulating data... just not my data."
                        It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                        RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                        Comment


                          #27
                          Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

                          IMPORT/EXPORT, DUPLICATE, DROPPING/ADDING. (This is a composite of bugs!)
                          [via the control panel]
                          v.11 (Build 3197 Addins: 4070) ~ 01/22/2013
                          History: Unknown.
                          Status: DOCUMENTED & SUBMITTED

                          FILE MANIPULATION BUGS:
                          One of the issues below occurs only under an additional set of circumstances not mentioned below.
                          I believe this is the case with the first bug on the list below. (I will check notes and provide an update later this evening.)
                          • An exported form layout (.a5pkg) can not be imported into a new database if the the old database (from which it was exported) is also located on the same machine. What ends up happening during (attempted) import is: A second instance of the layout it added to the original database that isn't even open. Just prior to this, the import routine incorrectly indicates the layout already exists on the open database, even though it doesn't. The screen capture at bottom is the screen that should come up instead. If you temporarily rename the database directory from which the .a5pkg was created, the import process will work as expected.
                          • Mapped table duplication fails. Duplication creates an empty .dbf without any data, regardless of settings chosen. (Duplication process does not invoke the right set of options/duplication window.)
                          • After duplicating a set that has a form with an embedded "stand-alone" (named browse) which is based on the entire set itself (instead of a table in the set): The new "instance" of the form needs to be manually edited. The "stand-alone" embedded browse on the new form does not reflect the new (duplicated) name of the set, from which the new form is based on. (The a5 "set duplication process" fails to take into account the possibility of a form containing "stand-alone" browse based on the duplicated set's name, which now has a new name.) The two browse property fields (on the form browse object) that need manual updating are: "Primary Table" & "Use named browse" fields. ~ upon duplication, second field is completely blank.
                          • Another bug (possibly related to the problem immediately above) is that if you attempt to change both the "Primary Table" & the Use named browse" field (on a form's "stand-alone" browse properties setup tab), only the first field "takes." You have to go back & right click (to edit properties again) to re-select the "Use named browse" selection.


                          NOTE: If you are familiar and comfortable with the internal filing system a5 uses, you can get around most of these issues with a good file explorer via drag & drop.

                          Snap 2013-01-23 at 11.09.23.png
                          Photo associated with first problem in list.
                          When importing an .a5pkg form layout, this screen should appear. (Instead you ALWAYS get a screen notifying you the layout already exists, even when it does not. And the import routine ends up either adding (or overwriting) the layout to the original database. (unless you have temporarily renamed the other databases directory) ~ When importing a layout you should always get this screen so you can specify which table/set the layout needs to be attached to. (Critical in the event the underlying table/set name is different in the "import" database that is open.)
                          Last edited by SNusa; 01-24-2013, 09:50 PM.
                          Robert T. ~ "I enjoy manipulating data... just not my data."
                          It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                          RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                          Comment


                            #28
                            Re: v.11 Desktop Anomalies & bug list (legitimate contributions welcome from all)

                            UNEXPECTED CHARACTERS TO AVOID USING IN A5 NAMING CONVENTIONS (And a problem with the "*" character in field data!)
                            v.11 (Build 3197 Addins: 4070) ~ 01/22/2013
                            History: Unknown.
                            Status: DOCUMENTED & SUBMITTED

                            When assigning (changing) the names of fields while setting up mapped tables: Do not use the hyphen key anywhere in the fields name. "-" Everything looks OK, but when you begin using the mapped tables, you will have issues. One example is using this mapped table to display a look-up box. (Selecting that field to display will cause the look-up field to not return any results. Other controls (in the a5 toolbox) may also FAIL. On a related note: The preview button does not always work in the "Record-List List Box" control. Based on the preview (an empty white box) you may thing there is a problem, even without using a hyphen. But running the form, you find it works fine. (providing no hyphens are used in the fields of the mapped table)

                            You may not have any control over this, but the asterisk key at the beginning of a text field causes "Query By Form" (invoked from either a right click on the field, or by selecting it in the a5 menu) to FAIL. ~I just hope this is a problem that does not effect X-basic commands (at a programming level) like <form>.viewqueried() etc.....
                            Robert T. ~ "I enjoy manipulating data... just not my data."
                            It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                            RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                            Comment


                              #29
                              Re: v.11 Desktop Anomalies &amp; bug list (legitimate contributions welcome from all)

                              OLD STYLE "POPUP" PROPERTY BOXES ~ DON'T ASSUME THAT WHAT YOU ENTER ACTUALLY "STICKS" (Sometimes, settings are deleted too!)
                              v.11 (Build 3197 Addins: 4070) ~ 01/22/2013
                              History: Unknown.
                              Status: DOCUMENTED & SUBMITTED

                              In several different objects, I have experienced some settings/changes (made with the old style "property boxes") to get lost after selecting OK.

                              A few examples:
                              • "Stand-Alone" browse (aka named browse) in the browse tab. ~ Editing properties does not always "take." (With some settings, you may have to repeat the process occasionally, and or toggle some other setting to make changes "stick." (Sometimes only one change "takes" and you have to go back and make the second change afterwards.)
                              • "Stand-Alone" browse (aka named browse) object placed on a form. (Right click on the form object and select properties) ~ Sometimes not every change made "takes" and you have to go back and make the second change afterwards.
                              • Be careful editing form events. Sometimes when you select Form -> Event -> Popup Editor (although you will see all the correct form events displayed in the menu/list): But when you click on the "Popup Editor" at bottom, the events that appear are not necessarily the same form events you just saw in the list. (The events you may find yourself editing are the events associated with the last form object that had focus.) ~ On more than one occasion, I quickly entered code only to think it had mysteriously vanished/disappeared. (until the code executed unexpectedly, triggered by an object on the form)

                              Unexpected property deletion example:
                              When editing properties on a "stand-alone" browse (what you refer to as a "named browse"): Under the filter/order tab, if you have previously created an ORDER EXPRESSION and you click on the builder to edit (or view it)..... Cancelling this edit process (after reviewing the ORDER EXPRESSION) results in this field (the order expression itself) being cleared. If you don't realize this has occurred & you subsequently hit the OK button (instead of the cancel button to close the browse properties window), the browse property window closes & the previously entered order expression is effectively deleted..... (This happens when you are working with a "sort selection" that has previously been converted to an expression.)


                              ~I don't believe that the "Panel Panes" (which expose a lot more properties) have this issue, so use them instead? (I still prefer the "popup property boxes" for basic editing because it's easier (visually) IMHO to find what you want "faster." ~ So many selections otherwise it's easy to become "lost in the list."
                              Last edited by SNusa; 01-25-2013, 10:24 AM.
                              Robert T. ~ "I enjoy manipulating data... just not my data."
                              It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                              RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                              Comment


                                #30
                                Re: v.11 Desktop Anomalies &amp; bug list (legitimate contributions welcome from all)

                                BROWSE SCROLLING HAS SOME GLITCHES (Regardless of which "Vertical Scroll Bar Behavior" setting is selected under a5 program settings.)
                                [Browse data is there, it's just not always easy/possible to navigate it.]
                                v.11 (Build 3197 Addins: 4070) ~ 01/22/2013
                                History: Unknown.
                                Status: DOCUMENTED & SUBMITTED
                                • Not worth going into details, but there are circumstances where although browse scrolling works fine from keyboard input (up/down keys etc.), the slider is virtually useless when you try to navigate the browse with a mouse. In these instances, (lots of data in the browse that "over-fills" the browse window): You will notice that if you use the arrow keys to move up and down the browse, every 3'rd key stroke results in the browse slider "glitching" and moving (bouncing) up to the top. On the very next keystroke, it returns to where it is proportionally expected. (It does not matter which browse setting you have selected in a5 program defaults.)
                                • There are also other circumstances when a (1 to many) browse (setup with the "Parent Records Only" option unchecked) results in browse data that cannot be seen because scrolling down the browse (even via the keyboard up/down arrow keys) results in the cursor scrolling "off browse" and out of sight. (Cursor disappears below the scroll window, because the window is not "scrolling.") ~ On a browse (not on a form), the only way to see this data is to vertically expand the browse window, in which case, you are still limited by vertical monitor/screen space. (since scrolling is not working) On a form, you are completely out of luck when this happens. (Because an embedded browse has a fixed area for display, which cannot be expanded vertically when the form is running.)


                                In several posts here in the forum, members have experienced field data (displayed within the browse) actually changing values when the field gets focus. I refer to this as "field data display ghosting." (So when you navigate around within the browse, new values "appear" to be written to the fields as the fields get focus.) This does happen, and here's one scenario:
                                If you 1.) Have a "one to many" (stand-alone / named browse) based on a table embedded in a form and the "Parent Records Only" option of the browse is unchecked (Control Panel browse tab browse property setting). AND 2.) You are calculating "grand totals" of a field in this browse (which incidentally calculates correctly.) ~ You will experience this anomaly! A workaround here is to create the "stand-alone" (named browse) based on the entire set (as opposed to one table in the set) that the form is based on, and not use the "grand total" calculation. (When creating a total for the field using the wizard, after dragging & dropping the field on the form: You will see a notification that the wizard has made some "assumptions." ~ Selecting "advanced options" allows you to generate a modified calculation that works on the set based browse AND does not exhibit "field data ghosting" as I refer to it. (Changing this setting effectively gives you the total calculation you want without "field data display ghosting.")

                                There are several other browse navigational/display problems too. In general, I have found the old browse "Vertical Scroll Bar Behavior" setting to be more "forgiving" in most instances.
                                Last edited by SNusa; 01-25-2013, 10:39 AM.
                                Robert T. ~ "I enjoy manipulating data... just not my data."
                                It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                                RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                                Comment

                                Working...
                                X