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

Global variables in report break expessions

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

    Global variables in report break expessions

    Selwyn,

    Re: My question about Dynamic Group Breaks in Reports: I tried John Zaleski�s suggestion but the break expression in the report writer does not take calculated fields any more than it takes global variables.

    I think you should seriously consider making the break expression in the report writer take global variables with field names as values such that having the variable in the break expression would cause the report to break on changes in the field�s value [maybe your left(eval(var->br),1) would work if the break expression would take the global variable].

    Having this ability would allow us to build a kind of report generator for users, which is essentially what my client wanted me to build. The more complex story of what I was trying to do was as follows:

    1. Build a common report detail section that gets used in any number of �different� reports (different mostly obviously in the group breaks but different in other ways too). In this case it was to print landscape on legal 14" paper, so it has a good number of fields, many of which are dates.

    2. I put some fields and their labels in conditional objects so they would print or not depending on global variables set in a dialog form. One example for this client was a field that calculated (in a non-obvious way) a broker�s gross profit on a mortgage loan. The boss wants that field to print but for his staff he wants he wants a different field to print in that spot. He has not asked for this yet, but one might also set up the dialog so that users could click on a number of field combinations they might want or not want on the report. You could also have entire summary sections for a group show or not show on a conditional object. This is all do-able right now and what I have tried works very well. You might say, why not just build separate reports? But will be apparent below, we are talking about a large number of separate reports here.

    2. My client wants the user to be able to pick from a list of 7 date fields to be the date used for the user specified date range for the report run. Again, nothing to it as you can use variables for the date field name and the dates. (Well, it is a little tricky to set it up, but as usual in Alpha Five it can be done.)

    3. My client also wants to be able to specify the sort (including ascending/descending) for the detail records in the groups. Again, no problem.

    4. Lastly, my client would like the user, sticking with just this one long and somewhat complex report layout of fields, to be able to select 1, 2 or 3 fields from a list of 10 fields to be used for up to 3 group breaks in the report. This too would all be easily do-able if the break expressions could take variables. But without this final piece to the puzzle I am faced with copying the first layout many times (I don�t even want to think about how many times!) and then modifying each to cover one the numerous possible break situations he wants covered. Not only is that a lot of work, I�ll inevitably have a lot more work to do when he wants even a simple modification to the basic layout. Whatever work it amounts to it could mostly be avoided if there were only the one layout to deal instead of God knows how many.

    Now, independent of this client, I think this would be very flexible, powerful tool in the Alpha Five arsenal. Of course for a single table or set one could also build other report layouts that could be used with this report generator dialog (just add a drop down for �Which report layout do you want generated?�), making it an even more powerful tool.

    Anyway, I think you should consider all this, especially if it is not a big task to make the break expression take global variables.

    Raymond Lyons


    #2
    RE: Global variables in report break expessions

    Ray,

    Before you start duplicating and modifying all those similar (identical) report layouts, consider the possibility of adding a new field to your table, and then using it to break your report into groups. I am thinking maybe all you need to do is a bit of pre-processing before each report is run. A simple script could clear the new field, re-fill it with values which match the desired group break sequence your client wants for the current report, and then reindex the table on the same field. Doing it this way the report always breaks groups on the one field, but the values stored there are 'variable' depending on which 'version' of the report your client may want. What do you think? Wouldn't that be easier?

    -- tom

    Comment


      #3
      RE: Global variables in report break expessions

      I believe the break expression in a5v5 will take a calculated field and it will not in version 4.5.
      Did you try this in a5v5??

      Comment


        #4
        RE: Global variables in report break expessions

        Tom,

        Thanks for the idea. Yes, it probably would be easier than the alternative, but of course it would still be easier if the the break expression took global variables. Plus I still think that would be an attractive feature for A5, even if few may have thought about how they could use it.

        Ray

        Comment


          #5
          RE: Global variables in report break expessions

          John,

          No, just 4.5. However, I will try it in v5 this afternoon. I have mainly been trying things in 4.5 because I have yet to succeed in talking this client into moving to v5. If this worked in v5 but not in v4.5 that would clinch another license for Alpha!

          I will let you know whether it works in v5.

          Ray

          Comment


            #6
            RE: Global variables in report break expessions

            Tom,

            I am not sure what I did is exactly what you had in mind, but in any case, thanks to your suggestion, I have the basics of a report generator built and it is working great so far. What I did is this: I created 3 new character fields for the possibility of 3 breaks in the report. Then through Xbasic I merely update those 3 fields with the data from whatever fields the user selects, using dtos()to appropriately transform the date fields [dtoc()would work but it would not result in chronological ordering as dtos() does]. The only real negative I see is that if the table were large the updates to every record would slow things down a bit. I suppose I could just update the records that will be in the print range selected, but with the relatively small table my client anticipates it is not worth the trouble.

            I still hope Selwyn reworks report break expression so they can take global variables, but until then (if ever) you have saved my butt.

            Thanks,

            Ray

            Comment


              #7
              RE: Global variables in report break expessions

              John,

              Thanks, but calcs don't work in v5 either.

              Ray

              Comment


                #8
                RE: Global variables in report break expessions

                Ray,

                I'm glad you got it going.

                The difficulty in using a global var to identify the 'group break' field may be that this would be sort of like modifying the report layout itself at print time. I'm not one of the designers of the report engine, but I've always imagined that the specifications for the layout, including fields, positions, colors, included regions, excluded regions, and grouping information (including ordering, sorting, etc) are stored when you save the report layout. Instead of saving a specific value you're wanting to store a variable that can have ANY value at print time. You want the report engine to be smart enough to evaluate the variable, and then change it's ordering and sorting arrangements to match the new group break field... all at print time. This is kind of like wanting the report engine to be smart enough to redesign the report layout itself at print time.

                -- tom

                Comment


                  #9
                  RE: Global variables in report break expessions

                  Ray,
                  A second difficulty with your method beyond being slow if you are dealing with a large table is that it won't work very well in a multi-user environment.

                  I'm not sure what you were looking at, but using a5v5 build 1009 I was able to to use a calculated field in the report break expression.
                  Here's what I did.
                  1) create a global variable called "choices" with three possible values "1" or "2" or "3"
                  2) in the report created a calculated field called "RP" equal to the value of the global variable
                  3) created another calculated field with the following:
                  sortme = if(RP = "1",lastname,if(rp = "2",dtos(date1),if(rp = "3",dtos(date2)," ")))
                  4) put the calculated field in as the report break expression
                  It worked.

                  Comment


                    #10
                    RE: Global variables in report break expessions

                    Correction:
                    sortme = if(calc->RP = "1",lastname,if(calc->rp = "2",dtos(date1),if(calc->rp = "3",dtos(date2)," ")))

                    Comment


                      #11
                      RE: Global variables in report break expessions

                      John,

                      Yes, I thought of the multiuser problem and though I have yet to do it, I have thought of at least partial ways around the problem (e.g., either a temporay or permanent file linked to the one with the real data would deal with some if not all the multiuser issues).

                      However, if you have gotten calulated fields to work in v5 I have to go back and look at that again. V5 would not accept the calculated field I tried to use (not a matter of it not working, it wouldn't tolerate the valid calculated field even being there). But obvioulsy I have to look at it again.

                      Thanks.

                      Ray

                      Comment


                        #12
                        RE: Global variables in report break expessions

                        John,

                        This is interesting and somewhat perplexing. Since I already had a global variable, I tried using it and its values modeled after what you did. v5 (1296-1009) would not even let me close the window with my calc field in it ("No such field"). Then I redid things using your example to the letter and it took it! Then I went back to my 1st attempt and it took that!!!.

                        Moreover, v4.5 will take the same calc group scheme and my report seems to get sorted correctly. In v5 it's hard to tell as yet because v5 rejects the v4.5 report filter I am using (see other thread posted today). If Selwyn (or someone) can't tell me what the deal is with the filter I will have to try to figure it out. The way report filters work seems to be fluctuating between v4.03, v4.5 and now again with v5. Oh well.

                        Ray

                        Comment


                          #13
                          RE: Global variables in report break expessions

                          John,

                          The good news is that using a calculated field works with 1 sort or group. However, if one wants 2 or 3 it will run but nothing is sorted correctly. I'm sure there is logic as to why more than one calculated field (as sorts) won't work in this context, but I am not going to waste time figuring it out.

                          What is still needed not just being able to have the group expression take a variable but the varible's value can't just be a string consisting of the field name. At least I don't think it can.

                          Thanks again for the help.

                          Ray

                          Comment


                            #14
                            RE: Global variables in report break expessions

                            I tested it for 2 sort groups and it seemed to work fine.There may be other factors involved in your report, but on a simple table, it worked okay.

                            Comment


                              #15
                              RE: Global variables in report break expessions

                              John,

                              As best as I can recall, my test report did the following:
                              I was using a date field for report print date range (which ends up being the last sort of there are any others. As a sort I was inverting that outside of the report layout, but not inverting did not help the problem.

                              Then I need 3 groups as calc fields (values coming from global variables outside the report layout), My test fields were House Rep, Broker and Broker rep, all of which came out appropriately when using actual field names but not when using calcs. My test report had group headers and footers (though I am pretty sure I tried it without to see if it mattered).

                              The bad result was something like the following: The report showed the first House Rep in the first group and maybe that person�s proper records (but I don't think that was even correctly shown). In any case virtually everything else came out wrong, including records that didn't even print though they did when using fields instead of the calcs with the same other print parameters. After trying everything I could think of and not being able to access this board, I through in the towel went back to a version of Tom's suggestion with code that would give my own error message when another user is in change mode when I am preprocessing records. But I still would like to go back and see if I can make calc fields work. Would you mind sending me a database sample of what worked for you so I can where I possibly went astray?

                              Ray

                              Comment

                              Working...
                              X