Re: Table Style Reports

From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 08/26/04 

Date: Thu, 26 Aug 2004 11:44:26 -0400

for(int i = 0; i < c_MyList.GetCount(); i++) would be a good start. Then just write the
data out, e.g., as a comma-separated list (which also makes it easy to import to Excel,
SQL Server, etc.) with a filename of the form yyyymmdd.txt in a special directory.

I would be sorely tempted, in the case where there is a desire to examine past data, to
use MDI and remove the FWS_ADDTOTITLE bit, so if someone wanted to open some earlier
report, I'd just create a new doc/view for that file, change the title to some readable
string (rather than the filename), and this saves the problem of how to "save" live data
while other data is being examined.

By using doc/view, it also means that the data can be thought of as part of the document,
so as new data comes in, it can be appended to the existing file-of-the-day (if the rates
are low enough, an open-seek-to-end-write sequence would not have a noticeable impact on
performance), and the view just represents the current document. This means that if you
shut the program down and restart it, you first go out and read the file-of-the-day and
load its contents into the CListView, thuse providing a seamless integration of the
existing data with new incoming data. Note this means you don't have to worry at all about
iterating over the list to save the data.

If I was forced to use a dialog-based app, I might consider having a second CListCtrl
which I make visible to hold data being examined, while the "live" list control was
rendered invisible during this period. But I think MDI would be the better approach,
because it would allow viewing several days' worth of output concurrently.

I've already done this in a past app, but we actually used a database library to get
database interfaces to do it, but a simple text file with your own parsing, or,
alternatively (and "more modern") an XML file would be suitable representation.
                                joe

On Thu, 26 Aug 2004 02:09:03 -0700, "Macca" <Macca@discussions.microsoft.com> wrote:

>Hi Joe,
>
>Thanks for the reply.
>
>i'll try and give you a bit more information. My system will log data during
>the day and they collate it all at the end of day into a formatted report.
>
>Now the user will be able to select what day they want to see a report of.
>This will be displyed on GUI but will also be available to print out.
>
>Now this means archiving each days data so that it can be accessed in future.
>
>With the excel option i can build a spread*** at the end of each day and
>then open it when that day is selected.
>
>With the ListCtrl i need to make the data persisent before filling the
>ListCtrl with the necessary data.
>
>At the moment i don't have a database which would be logical destination to
>store data. I need a fairly quick solution so i'm leaving database option
>till later.
>
>Any suggesstions on how i could make data persistent for ListCtrl without
>using database?
>
>Cheers
>Macca
>
>
>
>"Joseph M. Newcomer" wrote:
>
>> That's certainly one way. There are at least three others which are probably an order of
>> magnitude easier.
>>
>> The simplest by far is to use a "Report View" CListCtrl. You can fiddle the column widths,
>> and you get horizontal and vertical scrolling free. With owner-draw, you can change the
>> colors of individual cells if this matters.
>>
>> You can also use an owner-draw CListBox, which is a lot easier to use in terms of control
>> of the formatting, but a lot harder to use in terms of having columns automated so you can
>> easily dynamically adjust their width from the GUI (I've done it, and it isn't all THAT
>> hard, but it is harder than using a CListCtrl. I did this when we needed owner-draw before
>> CListCtrl supported owner-draw)
>>
>> You could also use a grid control of your choice, including MSGRID if you can tolerate it.
>> One of those cases where some things are harder than a CListCtrl (like, for MSGRID, the
>> interface is nearly undocumented and basically sucks) but many other things are vastly
>> easier (e.g., setting cell text color, font, and size).
>>
>> Given your situation, without more detail, I'd consider any of the above three to be
>> equally poised as solutions. After I understood the details of the problem better, I might
>> choose one as being the best compromise of simplicity of programming with functionality
>> desired.
>>
>> Printing is usually much harder, and the issues of printing are comparable to those of
>> doing owner-draw CListBox without the advantages of horizontal scrolling. For example, I
>> had to compute the correct font size that would cause all the columns to print out on an
>> 8.5" width, and allow the user to choose Landscape and then adjust it for an 11" width (so
>> the user could get a larger font). In most cases, you will have to do something like this
>> so it reconfigures for any sized paper (think: Metric markets, people with legal and
>> tabloid printers). Perhaps some grid controls have such features built in, but I've not
>> tried printing except by writing my own code for a long time. Grid controls actually turn
>> out to be a bit easier to manager for such printing because you can write a uniform
>> subroutine to print a cell, whereas the other cases generally involve writing different
>> code for the screen representation and the printed representation. But sometimes this
>> isn't such a Bad Thing because you may want flexibility in doing the printing. No one
>> simple answer, as far as I'm concerned, just a lot of tradeoffs.
>> joe
>>
>> On Mon, 23 Aug 2004 06:53:02 -0700, "Macca" <Macca@discussions.microsoft.com> wrote:
>>
>> >Hi,
>> >
>> >I am writing an application that will output results to a table style
>> >report(Information in columns and rows). This report will be able to be
>> >viewed through the GUI and can also be printed out.
>> >
>> >I'm not sure the best way to go about this. I was thinking possibly writing
>> >values to an excel spread ***.
>> >
>> >I'd appreciate suggestions on this idea and any other possible solutions
>> >
>> >Thanks In Advance,
>> >Macca.
>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm