Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
(OP)
I have a form with a search-list (incremental search).
Works fine.
I only have to type 1 to 3 letters - and I'm already on the right line - and with one click a browse window opens and shows me detailed results from a table.
This is of course easier to represent than to a GRID on the form.
You can also navigate in a browse window without writing any code oder filling headers etc.
My question:
Can a reduced BROWSE window be shown on the form at the same time if there is still enough space on the form?
Or - can a BROWSE windows can only be displayed on their own - but this means that the BROWSE window must first be closed manually in order to get back to the search list on the form.
I hope this question is not too stupid.
Up to now I always tryed to avoid GRIDS - but may be that this "fear" is exaggerated
I am very interested in your opinion.
Klaus
Peace worldwide - it starts here...
Works fine.
I only have to type 1 to 3 letters - and I'm already on the right line - and with one click a browse window opens and shows me detailed results from a table.
This is of course easier to represent than to a GRID on the form.
You can also navigate in a browse window without writing any code oder filling headers etc.
My question:
Can a reduced BROWSE window be shown on the form at the same time if there is still enough space on the form?
Or - can a BROWSE windows can only be displayed on their own - but this means that the BROWSE window must first be closed manually in order to get back to the search list on the form.
I hope this question is not too stupid.
Up to now I always tryed to avoid GRIDS - but may be that this "fear" is exaggerated
I am very interested in your opinion.
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Use a grid.
Tamar
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
I suggest you read the help file about the BROWSE and the DEFINE WINDOW command
AFAIK - No, it can be only shown in the main VFP Screen, can overlap the form, but CANNOT be shown IN the form
No, you may program it in order to CLOSE when it looses focus or after a certain TIMEOUT you specify.
Well that's your decision but you may want to rethink it - GRIDS are in may ways more powerful than BROWSE
Below a sketch of code how you could address this issue.
CODE -->
hth
MarK
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
My answer is Yes
But I am willing to relearn and experience the benefits of a Grid
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
If you know the structure and the intent (business object) go for a grid
If you don't know the structure, a browse is good.
Ten points to T!
Regards
ing
Griff
Keep
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
There is no place like G28 X0 Y0 Z0
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Is it that you need to set so many grid properties and the columns to get the same? Actually a grid you set to rowsourcetype alias and open up an alias automatically becomes a browse of that alias, without further ado. And a FOR clause is just a SET FILTER of that alias..
There's more to browse, but in the end it is a grid, really.
Do your favorite/most complex BROWSE command, but add NAME browsegrid NOWAIT, and then do
browsegrid.saveasclass('mygrids.vcx','thisgrid')
Open the class in the class designer, use the properties window and set it to "nondefault properties only" and you see which specialties (if any) of the grid and its columns are used. On the grid level mainly you have a column count specific to the fieldcount of the workarea you browsed. And in all the columns you have the controlsource of a field. That's mainly all there is to it.
PS: As I see Mikes adice, I want to add that this method(saveasclass) has pros and cons in comparison with Mikes suggestions. First, saveasclass is not special, it's available for any class/object and I pointed it out as it enables you to inspect what the browse command you used actually set up as a grid and at the same time to show the browse actually is a grid. What's not saved - as it's not actually properties of the grid - is which DBFs are open in which workareas, so to use such a grid class later, you still have to open the table first. Mike's way to drag a table onto a form - especially in the case you drag it from the data environment - ensures that you have that DBF open, when you run the form. As always you can also get help to configure a pure empty grid you put on a form from the form controls toolbar, by a right click on it and using the builder. So there are many ways to get to a populated grid.
SaveAsClass is a simple way to "conserve" an object and its current state, too. So one advantage of the saveasclass method is that you can inspect how you get to the same grid as the browse command you used and more generally how a control or any object is set at the time you save it as a class, so it's also a tool for debugging and inspection of a state something was in at the time of saving it.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Keep it simple!
Below a sample how to combine a GRID with INCREMENTAL search and COMPUTED columns.
CODE -->
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
You should definitely take the trouble to learn to use a grid. It gives you everything a Browse gives, plus a lot more. And once you have understood how to use it, it is not at all difficult to program. Browse is useful in the development environment, but the only reason to use it within an application is for backward compatibility with Foxpro 2.x and earlier.
Griff makes the point that you should use Browse If you don't know the structure of the table. But that works for a grid as well.
Deciding to use a grid is a bit like deciding to learn object-oriented programming. You can manage perfectly well without it, but you are not really getting the full benefit of VFP.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Tamar is right. 10 points to her.
Grid is part of the form : if form gets resized or moved, the grid will be resized/moved with it without add.programming. Thats a big advantage if user uses 2 monitors.
Grid has "Dynamic propertys" , so it can show for example columns/rows backcolor as green if an anmount is bigger then xxx and/or as red if the amount is less then yyyy. You can use function and make really complex conditions/colours.
If user moves to another row (or col) within the grid, an event is triggered. We use that to show details for the actual record on form after user moves to/selects another row.
Its very easy to have different fonts / attributes for each columns if you like and you can make columns invisible in runtime or change width,...
There are functions from VFP-programmers which automatically show sums/subsums or present data like a treeview or generate a report from grid (including formatting) with a click.
.....
The other tips should help, its realy worth it.
Best regards
tom
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
It is so far ahead of the equivalent in C#... just miles better.
The only place I use Browse over a grid is in my silly little 'on-the-spot' browser
utility that I install on my servers to enable forensic / ad hoc examination of tables.
Regards
ing
Griff
Keep
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
There is no place like G28 X0 Y0 Z0
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Having said that, I'm guilty of using BROWSE in some of my apps where I'm the only user. Instead of a grid, I just add a BROWSE button for a quick & dirty (& lazy) way to locate & change data. Old habit.
Steve
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
1. Open a form in the Form Designer.
2. Drag a table and drop it onto the form. You can drag it from the form's Data Environment, a VFP Project Manager window, or even Windows Explorer.
3. Save and run the form.
You now have a fully-functioning grid, showing all the data in the table. It's that simple. (But, of course, you will almost certainly want to customise the grid in various ways.)
If you only want to show specific fields in the grid, add the table to the form's Data Environment, then multi-select the fields you're interested in (hold down Ctrl and/or Shift while you select the individual fields). Drag these to the form.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Greg
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
My opinion, for what it is worth. Take the time to learn to use the grid. Even if you can get by without it right now, there will likely come a point where a browse window just won't give you the degree of control and options that you really need and a grid will be the solution. Embrace it sooner rather than later. You will be glad you did!
Alec
Santa Barbara, California
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
You can design the data structure with foreign keys and browse data this way, for example - making use of SET RELATION and BROWSE FIELDS:
CODE
This is not that straight forward, you need to dig into the xBase way of setting relations on one hand and also know about the FIELDS feature of browse capable to show fields of other workareas, on the other hand. So this requires several insights into how Foxpro works. And I bet you most beginners wouldn't go for that but simply have the hometeam and awayteam fields being chars and not have a teams DBF at all.
And even if you go that far, know all that, and do your browse this way, you now have readonly columns host and guest. The solution to that using the grid control instead of the browse is to have comboboxes in the team columns and use the team ids as controlsource to show the team name as a combobox item. and also be able to select a teamname and set the team id through it.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
I do not know, why.
So - again: Thank you all very much for your great and kind help - I am now also convinced that it is more efficient to work with GRID than with BROWSE - basically all answers say this in unison.
Too bad I can't spend a round of beer on it here -
that would be easy for me.
Now I need some time to familiarize myself with GRID.
The first question follows immediately.
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Thank you for your showing me an easy way for you to get started with grids.
That works with a table in this case named Aktien2.dbf
I can see now a form, and the grid1, which shows me all the fields of dbf Aktien2.dbf
The first field-name of Aktien2.dbf is named Ak2begriff
The question is now for me:
I added a commandbutton on the form and in the CLICK of that commandbutton I coded:
Select DISTINCT(ak2begriff) from aktien2 into cursor mycursor
because I wanted to see another content in the grid.
but then I struggled where the following questionmarks are:
SET FULLPATH on
SELECT distinct(ak2begriff) FROM aktien2 INTO cursor mycursor
thisform.grid1.recordsource = ???
thisform.grid1.recordsourcetype = ????
thisform.Refresh
What hast to be done or to be filled here?
Several trials from my side failed.
Thanks
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
This is where BROWSE simply creates a new grid initially having no columns that can then simply show what's in the current workarea., but once a grid has its columncount and column onbjects each with a controlsource, that doesn't change simply because you change the recordsource.
So you see a grids intent is not to use the same grid to show different workareas. You design it for one structure and then keep it at that. You can make columns movable, so you can interactively change column order, you can set column visibility to turn on or off columns, but once a column exists from the first recordsource the grid had, it's there until you remove it or until you close the alias that is the grids' source of data.
It's not hard to get to what you want, even if it's not the main intent. You can always get rid of the grid content by simply closing it's workarea. So do
CODE
Think about usual applications that use a grid or a control similar to it. Let's say the file explorer files list. You can have very different lists reorder items, resize their widths, pick columns to show or not show, etc. Well, and the VFP grid offers all that too, interactively. You can move columns, resize their width, you can not set them visible=.f. with the user interface alone, but this possibility can be given to the user.
If you would use this concept of closing workarea and setting a new one, you can't add permanent things to the grid that make it more useful than a browse, but at least you'd use the property of the grid to not be a separate window, but a control with position and size on the form. If that's all you need from the grid, then that's your solution.
A variation to not need to close the previous workarea is to remove columns before setting the new recordsource. This way works:
CODE
Interestingly, if you try the simpler Thisform.grid1.columncount=0 setting a new recordsource alias does not trigger the grid to create new columns. You then have to do
CODE
In the aspect of using the grid for such interactively changing data sources you waste some of the possibilities of the grid as you throw away the grid substructure and recreate it. But it's just as good as browses with a fixed position inside your form.
Now, if your next button should bring back the full aktien2.dbf, then you better have 2 grids in the form, of course. Keep grid1 to display aktien2.dbf and use something to switch grids. In the simplest case have a pageframe with 2 pages and a grid on each of them and set activepage. If you design a grid with all bells and whistles at design time, with dynamic coloring and code in column controls, you don't want to throw that away just to display something else temporarily. You could always integrate one such "throwaway" grid or even create new grid objects at runtime with thisform.addobject('gridx','grid') and thereby emulate creating browse windows without having the windows. But that's not truly the best use of a grid.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Don't use DISTINCT. From VFP Hacker's Guide
Furthermore I hope your DBF is indexed on ak2begriff - if not please do so. If you then = INDEXSEEK(...) or = SEEK(...) or SEEK (the command) the record pointer jumps to the 1st record found and highlights it in the grid - the subsequent records are shown below. Please have a look at he code I already posted or the one below (a slightly pimped up version of the former one).
CODE -->
LOCAL loForm loForm = CREATEOBJECT("clssearch") loForm.Show() Read EVENTS CLOSE ALL CLEAR ALL RETURN *********** DEFINE CLASS clssearch AS form Top = 12 Left = 12 Height = 474 Width = 1050 MinWidth = This.Width Caption = "Incremental Search" WindowState = 0 AutoCenter = .T. Name = "clssearch" Themes = .F. ShowTips = .T. ADD OBJECT lblName as Label WITH ; Left = 12, Top = 12, Caption = "Item to search :", FontBold = .T. ADD OBJECT lblFound as Label WITH ; Left = 270, Top = 12, Autosize = .T., Caption = "Item highlighted :", FontBold = .T. ADD OBJECT lblItemName as Label WITH ; Left = 270, Top = 36, AutoSize = .T., Caption = "", FontBold = .T., FontItalic = .T., FontSize = 12 ADD OBJECT txtBox as TextBox WITH ; Left = 12, Top = 36, Format = "!", ToolTipText = "Double-click to clear textbox" PROCEDURE txtBox.DblClick() This.Value = "" ENDPROC PROCEDURE txtBox.InteractiveChange LOCAL lcSearch lcSearch = ALLTRIM(This.Value) = INDEXSEEK(lcSearch, .T., "csrWords") WITH ThisForm .lblItemName.Caption = cWord .grdValues.Refresh() ENDWITH ENDPROC ADD OBJECT grdValues AS Grid WITH ; Left = 12, ; Top = 72, ; Height = 474 - 72 - 12, ; Width = 1050 - 24, ; Anchor = 15, ; BackColor = RGB(224, 224, 224), ; AllowRowSizing = .F., ; HeaderHeight = 21, ; AllowHeaderSizing = .F., ; DeleteMark = .F., ; HighLightStyle = 2, ; HighlightBackColor = RGB(0, 250, 250), ; HighlightForeColor = RGB(0, 0, 0), ; ColumnCount = -1, ; RowSourceType = 2, ; RowSource = "csrWords", ; ReadOnly = .T. PROCEDURE grdValues.Init() WITH This .SetAll("FontBold", .T., "Header") .SetAll("BackColor", RGB(0, 250, 250), "Header") ENDWITH WITH This.Column1 .Width = 246 .Header1.Caption = "Name" ENDWITH WITH This.Column2 .Width = 150 .Header1.Caption = "Value One" ENDWITH WITH This.Column3 .Width = 150 .Header1.Caption = "Value Two" ENDWITH WITH This.Column4 .Width = 150 .Header1.Caption = "VO + VT" ENDWITH WITH This.Column5 .Width = 150 .Header1.Caption = "VO - VT" ENDWITH WITH This.Column6 .Width = 150 .Header1.Caption = "VO + (2 * VT)" ENDWITH ENDPROC PROCEDURE grdValues.AfterRowColChange() LPARAMETERS nColIndex WITH ThisForm .lblItemName.Caption = cWord .Refresh() ENDWITH ENDPROC PROCEDURE Load() LOCAL lnI, lnY, lnWordLength, lcItem, lnUpper, lnLower lnUpper = 90 &&ASCII (Z) lnLower = 65 &&ASCII (A) CREATE CURSOR csrWords ( cWord C(20), iValOne I, iValTwo I, iValThree I, iValFour I, iValFive I) INDEX on cWord TAG tagWord SET ORDER to tagWord FOR lnI = 1 to 1500 lcItem = "" lnWordLength = INT(20 * RAND()) + 1 FOR lnY = 1 TO lnWordLength lcItem = lcItem + CHR(INT((lnUpper - lnLower + 1) * RAND()) + lnLower) ENDFOR INSERT INTO csrWords VALUES (lcItem, RAND() * 5000, RAND() * 1250, 0, 0, 0) UPDATE csrWords SET iValThree = iValOne + iValTwo, iValFour = iValOne - iValTwo, iValFive = iValOne + (2 * iValTwo) ENDFOR ENDPROC PROCEDURE Destroy() ThisForm.Release() CLEAR Events ENDPROC ENDDEFINE **********
hth
MarK
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
once again ...thank you for the many new information and hints how to improve my primitive program.
My knowledge dates back to 23 years ago when I retired.
But now I'm happy to get to know the whole development of VFP and OOP after 2002.
In addition, I also have to remember what I knew better than 20 years ago.
Not so easy when you are already 81 years old.
But that's just by the way....I learn more here than I did all the time before 2002.
That's why I only use my current program "quick and dirty" - it started in 2014 when I noted all sales of securities with the spreadsheet LOTUS 1-2-3, but that was much more tedious than it can be done with a database table today.
The table aktien2.dbf-structure is as follows:
and your assumption is correct - it is not yet indexed. The basic index should be on ak2begriff which is the name of a share, which repeats often in the table aktien2.dbf
and the form aktien2 looks like this:
The file "aktien2" is longer, but I shortened it.
All objects on the form show me stock sales in various groups (I used DISTINCT(ak2term) with summation .
e.g
Sales with gain or loss (ak2ergebni)
in total
by name of the day of the week
by name of a single stock via click(List1)
by calendar years
Etc.
This also works - the (old) browse windows are always used
shown where I also have the grand totals at the top of the title
display each.
But it's still totally old-fashioned - not the style of professionals - and
not friendly either, because of course you have to close the browse window again and again to get back to the form.
But it helps me with purchasing decisions, and I can always see if I'm broke or if it's worth moving on.
BTW - if someone tells you they always win at the stock market - run away quick - it's a liar.
I hope to have explained a litte more detailed, what I want to change.
(of course by using your hints then).
Thank you
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Your post raises more questions than we probably can help to solve
What struck me first is that "Gesamtergebnis" is the sum of "Gewinn gesamt" + "Verluste" and not the difference.
Furthermore you have a field called "ak2datum" and then fields like "ak2monat", "ak2jahr"... Are you aware that VFP has date/datetime handling functions like
and
You find them in VFP Hacker's Guide 7 - which you own and hopefully have read - see your thread184-1812467: Second hand books for Visual Foxpro
Finally I think you need to restructure you table(s) and "normalize" it/them, e.g. You don't need a field like ak2ergebnis since this is the difference between ak2gewinn and ak2verlust ...
And last - we can help you (re)coding. But the conception work will be your job, the computed results seems to have strong influence on your decisions where and when to invest your money.
Hope I wasn't too harsh
MarK
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
...
I forgot the crucial question: how and where would you like us to help you?
MarK
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Thank you for your inquiry and your valuable information.
it is by no means harsh - I even found them to be friendly.
In communication there was an overlap of questions by me and answers from you and others in the forum,
given.
(this is actually a good sign if everyone replies quickly),
but I didn't have the time to answer everything immediately.
Chriss had already suggested a solution that helps me,
from data condensed in a cursor in a grid.
answered my question to avoid switching between form and old Browse window.
Also all the other features of a Grid given by you and all others will help me to work with grids only in future.
But nevertheless your request/advice is still very useful for me.
This question is justified.
When I wrote it I had in mind 2 columns in the base file - one for wins and one for losses -
but of course it is automatically in the calculation and there are of course profits-losses = result.
May also could be a typo by me.
Thank you also for your hints on the evaluation of calendar dates in months, weeks, days.
I have also used these functions in the program, the base table receives an accounting date manually - and I run this directly into the columns of the base file for cmonth, cdow in the file via the program.
This makes coding easier, and given the size of the table, it takes time
maybe probably under a second.(replace-all command)
I can definitely use the other special features and considerations about calendar dates in your detailed information at some point.
Your last question
My Answer:
I intend to rewrite my programm from scratch and I intend to built in as much as what was suggested for improvement here.
However - when new questions arise, I know that the best help can be found here.
Stay healthy
Regards
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Using a grid is one step towards having the display within the form itself, reusing the rid is questionable for that matter, I already said what else I'd do, but it's still not clear whether I'm right in my guess you used the browse for picking one of the distinct value. If you do, what is done with this selection is still open.
I think I conclude this way here: I see how to handle the grid helped you here, if you have further questions you'll make further posts.
For the current phase and changing from BROWSE windows to grids, it might be helpful to your form design to have a single grid in the form which only has the purpose of showing the data you otherwise would display by BROWSE. Or are there cases, in which you have two or more BROWSE open at the same time?
I also would conclude that having a grid instead of a browse is only a minor improvement of the overall UI, as it just fixes the position and size of the browse. As I said already I think you're misusing a browse for a listbox or combobox to pick a value, not necessarily as an editing tool. Your query Select DISTINCT(ak2begriff) from aktien2 into cursor mycursor doesn't create a readwrite cursor so BROWSE of mycursor will only display it and you can move the record pointer to one of the mycursor records. That's what a listbox also does on a form, or a grid. A listbox is more appropriate for single column data, though indeed you can also display readonly data with multiple columns in a listbox, too.
For a complete rewrite the first thing I'd look into is the data rerstructuring, not the form restructuring, though. Maybe because I'm used to work on the basis of the right data design first. This is a rewriting straategy you couldn't do in small improvement steps. A new data structuring would require to also do all forms from scratch and not get away with slight modifications towards a final goal.
Chriss
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
That is correct.
It is the INIT-Method in List1 (the picklist) with this code where an array was established and filled with distinct(ak2begriff) -
**********************
CODE -->
...and in the Click-Event of List1 (the picklist) I wanted to show max. 50 records of a selected share in a browse-window.
CODE -->
As you can see, List1's main purpose is to show unique stock names and the results that go with them -
aktien2.dbf can contain e.g. 5 times the ak2begriff "TESLA" - therefore DISTINCT (in future this would better by using SQL ...GROUP BY)
The other commandbuttons are designed to provide summaries
have to show results by calendar year, or month, or day of the week. etc.
I simply made a practical way of entering new data records with (command-button - use aktien2.dbf - go bottom.)
It's definitely to do all this much more elegant and probably more efficient - and I would be happy to learn that.
It is never too late.
greeting
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Rainy day - had some spare time. Wrote something for you.
The sample code uses three cursors/tables: one for the shares, one for the buying history and one for the value history. The last two have a similar structure but their functions are totally different. Although the Buy/Sell commandbutton works with RAND() generated data there is no way (yet) to modify the saved data afterwords.
Maybe it gives you some hints. Enjoy.
CODE -->
MarK
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Thanks for the sample code which uses three cursors/tables.
It makes a very good professional impression - as soon as you call it up.
I think it can help me a lot to improve my own program code.
I don't necessarily need the routines for buying stocks.
I already get a statement from the bank that already shows the result of a transaction, namely:
a) Date of transaction
b) Order no.
c) Number of shares sold
d) Designation of the share
e) ISIN
f) Execution rate on sale
g) gain or loss
I enter this data manually into the VFP file (aktien2.dbf) - it's very quick - and you don't do that every day.
Then it just needs to be evaluated - and so I can see
what each sold title brought as a result,
a)with which title the most was won/lost,
b)on which day of the week the highest result (gain or loss) was achieved,
c)at what price it was last sold
d)what the result has been per year.
e)and of course also what the total result of all transactions was since recording.
Your program can give me useful information how to code this.
The file structure for my aktien2.dbf can now also be simplified.
I still have to invest a little more time to fully understand your program, but I have the time.
Thanks very much
Klaus
Peace worldwide - it starts here...
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
This is "No Country for Old Men" - hence we have to support each other.
I have been using my app for almost a week now feeding it with real world values. It showed that it had some quirks which I removed from the code (check below).
Now it works to my fullest satisfaction. As I said, it uses three tables, that are now created the first time you start it. A "Dummy" record is also created in order not to yield errors. This record is deleted asa you add a new record.
CODE -->
Enjoy.
MarK
RE: Advantage/Disadvantage between a BROWSE window or/and a building of a running GRID on a form.
Please show full video
https://youtu.be/RGmrxxQNiDo?si=oNouUYfOEtVhpnW3