Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Memo fields vfp7 add, edit, save, append 2

Status
Not open for further replies.

lrice

Programmer
Feb 19, 2007
11
US
Simple rosetta stone please for a
@ 4,4 say Memo field

@ 4,4 GET Memo field


Save Memo

anyone have code for doing this with VFP7 who woulddn't mind taking the time to send it to a programmer coming out of 15 year retirement. Would love to see a simple phone book style application written in vfp7 using old commands and then translated into whatever the new way is, but without using forms, i want to program it on screen myself.
 
Irice,

... written in vfp7 using old commands and then translated into whatever the new way is, but without using forms, i want to program it on screen myself.

I can't think of any good reason to do that.

Either use @/GET and @/SAY to write directly to the background screen (not recommended, but do-able). Or, much better, use labels and textboxes on a form.

In theory, you can place labels and textboxes on the background screen, but it doesn't really make sense to do so.

This is especially true for a programmer like yourself who is new to VFP. If you want to learn how to use the product, stick to the mainstream way of doing things, at least to begin with.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
I want to add my voice to Mike's. In VFP, it doesn't make sense to write I/O code by hand. You can do it, but it's tedious and difficult. The Form Designer lets you lay out forms exactly as you want them to look.

Unlike FoxPro 2.x, there's no code generation step, and what you see in the Form Designer is what you get at runtime.

For memo fields, the right solution is to use an EditBox control.

Tamar
 
You can do it, but it's tedious and difficult
And maintaining it is mindboggling difficult.

This form has two buttons and four text boxes on it. My morning's work is to add a fifth textbox. Actually my morning's work is going to be to recreate the existing form in the Designer and then add the fifth text box.

Code:
frmMyForm6 = Createobject("nc.FormForm")
frmMyForm6.Caption = "Part Details"
frmMyForm6.Height = (3*SPACEHEIGHT)+(4*LABELHEIGHT)+BUTTONHEIGHT
frmMyForm6.Width = 168+200+SPACEHEIGHT

frmMyForm6.AddObject("CustomCommandbutton1","nc.FormButton")
frmMyForm6.CustomCommandbutton1.Caption="OK"
frmMyForm6.CustomCommandbutton1.Default=.T.
frmMyForm6.CustomCommandbutton1.Top = (2*SPACEHEIGHT)+(4*LABELHEIGHT)
frmMyForm6.CustomCommandbutton1.Left = (frmMyForm6.Width-SPACEHEIGHT-(2*BUTTONWIDTH))/2
frmMyForm6.CustomCommandbutton1.Visible = .T.
oHandler = Newobject("myhandler")
Bindevent(frmMyForm6.CustomCommandbutton1, "Click", oHandler, "OKB")

frmMyForm6.AddObject("CustomCommandbutton2","nc.FormButton")
frmMyForm6.CustomCommandbutton2.Caption="Cancel"
frmMyForm6.CustomCommandbutton2.Cancel = .T.
frmMyForm6.CustomCommandbutton2.Top = (2*SPACEHEIGHT)+(4*LABELHEIGHT)
frmMyForm6.CustomCommandbutton2.Left = ((frmMyForm6.Width-SPACEHEIGHT-(2*BUTTONWIDTH))/2)+SPACEHEIGHT+BUTTONWIDTH
frmMyForm6.CustomCommandbutton2.Visible = .T.
Bindevent(frmMyForm6.CustomCommandbutton2, "Click", oHandler, "CancelB")


frmMyForm6.AddObject("CustomLabel1","nc.FormLabel")
frmMyForm6.CustomLabel1.Caption = "Description:"
frmMyForm6.CustomLabel1.Top = SPACEHEIGHT
frmMyForm6.CustomLabel1.Left = SPACEHEIGHT
frmMyForm6.CustomLabel1.Visible = .T.
frmMyForm6.AddObject("CustomTextBox1","nc.FormTextBox")
frmMyForm6.CustomTextBox1.Top = SPACEHEIGHT
frmMyForm6.CustomTextBox1.Left = 168
frmMyForm6.CustomTextBox1.Visible = .T.

frmMyForm6.AddObject("CustomLabel2","nc.FormLabel")
frmMyForm6.CustomLabel2.Caption = "Unit Sell œ"
frmMyForm6.CustomLabel2.Top = SPACEHEIGHT+(1*LABELHEIGHT)
frmMyForm6.CustomLabel2.Left = SPACEHEIGHT
frmMyForm6.CustomLabel2.Visible = .T.
frmMyForm6.AddObject("CustomTextBox2","nc.FormTextBox")
frmMyForm6.CustomTextBox2.Top = SPACEHEIGHT+(1*LABELHEIGHT)
frmMyForm6.CustomTextBox2.Left = 168
frmMyForm6.CustomTextBox2.Visible = .T.

frmMyForm6.AddObject("CustomLabel3","nc.FormLabel")
frmMyForm6.CustomLabel3.Caption = "Standard Qty:"
frmMyForm6.CustomLabel3.Top = SPACEHEIGHT+(2*LABELHEIGHT)
frmMyForm6.CustomLabel3.Left = SPACEHEIGHT
frmMyForm6.CustomLabel3.Visible = .T.
frmMyForm6.AddObject("CustomTextBox3","nc.FormTextBox")
frmMyForm6.CustomTextBox3.Top = SPACEHEIGHT+(2*LABELHEIGHT)
frmMyForm6.CustomTextBox3.Left = 168
frmMyForm6.CustomTextBox3.Visible = .T.

frmMyForm6.AddObject("CustomLabel4","nc.FormLabel")
frmMyForm6.CustomLabel4.Caption = "Service Grade:"
frmMyForm6.CustomLabel4.Top = SPACEHEIGHT+(3*LABELHEIGHT)
frmMyForm6.CustomLabel4.Left = SPACEHEIGHT
frmMyForm6.CustomLabel4.Visible = .T.
frmMyForm6.AddObject("CustomTextBox4","nc.FormTextBox")
frmMyForm6.CustomTextBox4.Top = SPACEHEIGHT+(3*LABELHEIGHT)
frmMyForm6.CustomTextBox4.Left = 168
frmMyForm6.CustomTextBox4.Visible = .T.

frmMyForm6.CustomTextBox1.ControlSource = "mdesc"
frmMyForm6.CustomTextBox2.ControlSource = "munit_sell"
frmMyForm6.CustomTextBox2.Format="999999.99"
frmMyForm6.CustomTextBox3.ControlSource = "mqty"
frmMyForm6.CustomTextBox3.Format="999"
frmMyForm6.CustomTextBox4.ControlSource = "mgrade"
frmMyForm6.CustomTextBox4.Format="9"

frmMyForm6.AutoCenter = .T.
frmMyForm6.Show
frmMyForm6.Release

This is just part of a 1500-line prg file which creates three forms - the others are far too long to quote here. If I ever get hold of the writer of this monstrosity ...

Geoff Franklin
 
GeoffFranklin, thank you. That kind of machine generated code is exactly what I never want to deal with unless it's life and death situation. It's like html generated by a word processor. Hideous to make a change in it manually.

I recognize and appreciate what the other guys have said here about going "mainstream", but that is exactly why I quit the "learning curve" introduced by BG, when he took over computers with WINDOWS.

Please realize, we no longer get to program a computer.
We program inside WINDOWS, which BG can change any time he decides the cash flow is low. Remember the days when people had to go on site at MSFT to get their apps running right on his system, which he would not reveal to outsiders.

He is the world's best at the unholy priesthood of computer trick secrets. And that concept has been around since the 60's. It began at IBM. Was well established by the advent of the 360.

I have discovered to my dismay, after bothering to convert a simple DBXL lightbar menu that it eats 49% of my cpu
and I have a AMD DUAL CORE ATHALON 3800 with a Meg of ram
running multiple heavy programs only takes 3 percent, but run this simple vfp7 menu and it eats 49% even the exe uses 49%

Apparently the DO WHILE loop for the menu testing In_key
just gobbles up cpu. Is there a fix?

lb_sel=0
* **************** PROBLEM HERE, if walk away for hour, it locks screen ***
* and this must be where cpu is being used so much DO WHILE lb_sel=0

Do While lb_sel=0
lb_sel=Inkey()
Enddo

I have not found anyone anywhere who could program inside bgWindows like we could in DOS. It just doesn't happen.
He built everything sideways instead of Heirarchial.
Other window systems existed, some were good.
He added the apple mouse, and took over the world.
New generation programmers don't have a clue what I'm saying.
I wrote my first binary program in the fall of 1966, and loved DBXL/QuickSilver/Arago . Wrote apps for US Postal Carriers, your daily mail, GE development engineer,
Easter Seal, and other vertical markets. Excuse me for my distaste of the windows trainwreck which is designed to consolidate control into MSFT-BG like a phython inch by inch eating its prey. In a little while, college grads may not even know anything about DOS, the way its going. It'll be like BF, Before Ford, unknown history. And people will be glad to do their home business on internet storage and even their taxes and all their personal info, and not give it a second thought. And they are confident BG and Big Gov are guarding their personal information, just like our electronic vote system which now rules our elections.
He who counts the vote rules. No more little people able to count the vote.

But, all that aside, if there's a fix to the cpu, I'd be grateful. Thanks for your time, and I hope the best for you all.
 
Mike, I totally respect you and have read many of your posts to gain the impression you are very very good at what you do. Your comment and the one from TamarGraner are taken to heart as the solid advice they are. I recognize that as the "way to go" of the many many multitudes. You are right.
Go with the flow, least resistance and all that.

However, just for understanding, and connection to my roots,
i have this desire to see what can be done in windows
WITHOUT resorting to WIZARDS.

WIZARDS have a way of leaving my understanding for changes out in the cold. I was trained to avoid other people's black boxes. Contributing to this mind-set is the fact that at one time, on the very very old computers, discreet components, I understood and could fix anything, any part, hardware or software. So I'm feeling robbed of even the ability to access anything without using a black box which generates code like the sample given by the church programmer above.--> Geoff Franklin


So far, my progress has been to use WINDOWS for my @ SAY GETS
and it seems to work quite well for me. Not trying to use the main screen, instead Defining windows and using those.

Only big problems seem to be the memo fields
and the cpu % useage of some do while loops.

lb_sel=0
* **************** PROBLEM HERE, if walk away for hour, it locks screen ***
* and this must be where cpu is being used so much DO WHILE lb_sel=0

Do While lb_sel=0
lb_sel=Inkey()
Enddo
 
"For memo fields, the right solution is to use an EditBox control"

Thank you for referring me to EditBox control

I will attempt to use that inside a window
perhaps with MODIFY MEMO command.

So far, I've found a way to just MODIFY MEMO
but can't much control the window size when it opens.

I shall walk down the path you suggest for Edit Box
 
Geof, what fun is that? Torture mill! Somebody wrote that by hand?!

I looked at the help in vfp7 for EditBox control
Typical bg it gave some definition with no examples of how it fits with other code. Useless, except to let BG have something in a dropdown window whenyou go looking for "help". but the help is helpless. as nearly always in a msft product.

anyway, I shall spend another few days trying , experimenting with various things I can find to use the edit box.

I found this place on the net, googling for source code examples. So far, zero.

Bill Gates idea of HELP on EditBox
Creates an edit box.

EditBox
Remarks
Use the EditBox control for editing a Character-type variable, array element, field, or memo field.

All standard Visual FoxPro editing features, such as cut, copy, and paste, are available for the edit box. The text in the edit box scrolls vertically and words are wrapped horizontally.

For additional information about creating edit boxes, see Using Controls.

See Also
EditBox Control Properties, Methods and Events | CREATE CLASS | CREATE FORM | DEFINE CLASS



--------------------------------------------------------------------------------

© 2001 Microsoft Corporation. All rights reserved.


Is there a board for "Replace BG MSFT" with anything else.




Larry A Rice
 
I'm responding to several of your messages at once. First, using the Form Designer and Class Designer is not using Wizards at all. I understanding why, coming from FP2.x, you might see it that way, but in fact, in VFP, no code is generated for a form; they run right from the SCX files.

Next, edit boxes. An edit box is an text input control which can handle multiple lines. In VFP, it's most suited to storing memo data. There's no need to use MODIFY MEMO at all in VFP.

On to menus. In the event-driven world, you don't use a loop to keep a menu alive. In VFP, the right way to keep it running without burning processor is to include the READ EVENTS command somewhere after putting your menu in place. READ EVENTS sets up a "wait state" that waits for the user to do something.

You won't need INKEY() for this, either. Whether you create your menu with the Menu Designer (which I recommend) or by writing DEFINE MENU, DEFINE PAD, DEFINE POPUP, DEFINE BAR, and ON SELECTION, ON BAR, etc. commands by hand, once you execute the menu and put your program into a wait state, the menu will respond to use input.

Finally, as for other people's black boxes, they're a mixed bag. The reality is that unless you're writing machine code, you're depending on something written by someone else to execute your code, whether it's an assembler, a compiler, a link library, or something else. So the key is to decide what you want to trust. Black boxes that are widely used are likely to be well-tested.

Tamar
 
Thank you Tamar Granor for your patience with this grumpy oldster who hadn't joined the next generation of stuff :)

It does feel very good to write a program the way I learned and run it in vfp7, and I've done most of it now.

I used to call a wordprocessor from DBXL and type directly into it from dbxl and then let the user add more like normal.

I have seen it is possible to RUN notepad from vfp7
but failed with wordpad. Discovered wordpad would also run if I copied it to the default directory of vfp7. But the user is likely to close it with the X of wordpad which leaves a nasty hanging DOS window which doesn't want to close. It all closes fine if the user exits by the wordpad menu EXIT. Anyway, what is the command to call wordpad and let it run in WINDOWS.

For page print, break, eject reasons I want to use wordpad.
I've looked through books and help files, but am too ignorant to find the code that would call wordpad inside windows.

Running WordPad from vfp in windows would be nice as contrasted to running from the dos shell.





Larry A Rice
 
declare long ShellExecute in "shell32.dll" ;
long hwnd, string lpszOp, ;
string lpszFile, string lpszParams, ;
string lpszDir, long nShowCmd

*lcFileToOpen = '"C:\My Folder\MyFile.txt"'
ShellExecute(0,'Open',;
'wordpad.exe',;
"",'',1)
 
As IlyaD showed you, you can run pretty much any program using ShellExecute.

An alternative, that offers you a lot more control and power, is to automate an application,such as Word from within VFP. To get started, you do something like:

oWord = CREATEOBJECT("Word.Application")
oDoc = oWord.Documents.Add()
oWord.Visible = .T.

Now you have Word open and visible with a blank document. However, the really powerful thing you can is not make it visible and create the document entirely with VFP code calling Word.

Another thing you can do is insert a Word object on a VFP form, so that users can actually see the Word document in your form and double-click on it to edit it.

Tamar
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top