$0 - Report Main Lists using Inst Var

Michael Houlberg michael at houlbergdevelopment.com
Fri Jan 29 13:33:52 EST 2010


Chris,

If you think you have found a legitimate bug, talk to Raining Data.

Whether it's a bug or not I can't say, but there is a scope problem in using an instance variable belonging to a window instance as the main list for a report instance.  If class variables worked before, then I think you were lucky because that shouldn't have worked either.

Next, take a deep breath.  You are already going through the monumental task of changing all your class variables to instance variables.  Using one of the work arounds for the report list that have already been suggested isn't going to be a big deal.  Maybe you can just leave your report list variables alone when you are changing all the others?  Maybe you don't need to use the Set Report Main List command if you assign the list in the report class to begin with?  There are other simple ways to solve your problem, but trying to jump out of the scope isn't the best solution.

Michael Houlberg
Houlberg Development, LLC

On Jan 29, 2010, at 10:22 AM, Chris Peck wrote:

> Hi Chuck,
> 
> You guys are not getting my point here ... It's is not that the style of coding you suggest won't work or that it is not probably one of the better ways to code a report construct nowadays, but that I have literally hundreds of report constructs which *already exist* in production code that I would have to do this to.  I'd need 6 months or more of free time (which I don't have) to just to convert every one of them to this style (not including testing time), though not all of the methods use class variables that I'm converting to instance variables.  We have here is what I believe is a bug in Studio that should be fixed, which would mean I won't have to worry about this issue.  I'm not asking for proper ways to construct a report in Studio, but rather if anyone knows how to get around the Set Report Main List command not recognizing an instance variable list as a list without having to do a lot of extra work.
> 
> Chris Peck
> Software Developer
> Word Master, Inc.
> 
> 
> 
> 
> On Jan 29, 2010, at 12:08 PM, Chuck Kirkman wrote:
> 
>> Hi Chris,
>> Why not send the report list as a parameter and then change the parameter to an instance variable in the report format? Then you don't have to change any of your class variables or generate the list again in the report format. Probably something elementary that you already knew, but it works quite well.
>> Chuck
>> On Jan 29, 2010, at 10:03 PM, Chris Peck wrote:
>> 
>>> Hi Michael,
>>> 
>>> Yes, I could do that, but that requires total re-writes of my existing reports and the code associated to them, i.e. tons more work on top of my already full days, so that is not an option, nor is it what I'm looking for.  The issue is that the Set Report Main List works with all variable types *except* instance variables, from what I've found during my experimentations.  I'm wondering if I've done something amiss here, that causes the command to error when using an instance var, or is it just a bug in Studio?  It can't be a scoping issue, as the command works fine with local variables inside the window instance, so why not with instance vars ?  I don't like having to remember to do this in every window where I generate a report that I convert class vars to inst vars.
>>> 
>>> If we're going to still have 4GL commands, they should be able to be used and not give errors like this, ya know?  Moving all of my report generation code to inside the report instances is going to take years of work, something I'm not ready to do yet.  Getting my windows converted from Classic coding styles over to Studio is a long and arduous job in the first place in an application the size of ours, but it is the first step, reports must necessarily come way down the road.
>>> 
>>> Chris Peck
>>> Software Developer
>>> Word Master, Inc.
>>> 
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com




More information about the omnisdev-en mailing list