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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

FOPEN() or APPEND FROM 3

Status
Not open for further replies.

linousa

IS-IT--Management
Mar 8, 2013
79
US
How to import data to dbf from text *.DAT file, tried "append from ? sdf", but it is confusing users with it's .txt extension. FOPEN() can't make it to append to dbf.
 
I'm just curious here...

What did you expect to get as a substring of an empty variable?
 
In my opinion, the best response when GETFILE() returns an empty string is to do nothing. The fact that the reply is empty means that the user does not want to do whatever action required the GETFILE() in the first place. The user cancelled the dialogue. There's no point in giving them a message to tell them that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Linousa said:
I know it is not possible to select multiple files in that getfile() dialog, do you know any workaround?

You can use the Windows GetOpenFileName() function. Or GetFileNameFromBrowse(). Both of these are described at news2news.com.

Alternatively, you can create your own dialogue using a listbox or treeview control, but that would be a lot of work, and wouldn't give any obvious benefit, as far as I can see.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
In my opinion, the best response when GETFILE() returns an empty string is to do nothing. The fact that the reply is empty means that the user does not want to do whatever action required the GETFILE() in the first place. The user cancelled the dialogue. There's no point in giving them a message to tell them that.

Well, yeah. Developers have a history of putting up interruptive messages that don't give the user any information. We do it because we can I think.

One of my favorites: "Are you sure you want to exit?"

Why yes, yes I am. I DID click the exit button after all. If I quit by mistake, well, I know how to restart the application. The message serves no useful purpose.

If I'm going to display a message that interrupts the user it must be informative and useful. Not just a pause for the sake of a pause.
 
Mike -
In my opinion, the best response when GETFILE() returns an empty string is to do nothing. The fact that the reply is empty means that the user does not want to do whatever action required the GETFILE() in the first place.

Dan -
Developers have a history of putting up interruptive messages that don't give the user any information.
and
The message serves no useful purpose.

I don't disagree with either of you.

But we all have to deal with our varied client/customer base (and their level of 'comfort' with applications) as best we can and that sometimes means going over-kill on messaging.
Too many times I have heard: "I DIDN'T MEAN TO DO THAT!"
And, depending on how many steps it has taken the user to get up to that point in the application, they might appreciate an 'Oops go-back' to quickly and 'knowingly' get back to that point in the code.
I guess that I personally have seldom heard: "You have too many user input messages" where this sort of input is used.

Additionally it is unknown if this Import filename input is a REQUIRED input for the application (obviously the APPEND cannot occur without it). Therefore the DO WHILE LOOP is included to support the possible REQUIRED input more effectively.

Not knowing the user-base that linousa is trying to serve, I included the extra (unnecessary???) messaging and DO WHILE LOOP - JUST IN CASE
BUT linousa is more than welcome to modify any part of the sample code to eliminate the messaging and/or the entire DO WHILE LOOP based on their own requirements.











 
Thank you everyone, especially jrbbldr, used your code with few mods!
About multiple files, tried that code snippet, which Mike suggested:
MikeLewis said:
You can use the Windows GetOpenFileName() function. Or GetFileNameFromBrowse(). Both of these are described at news2news.com.
But couldn't make it working, looks like GetFileNameFromBrowse() is the wrapper for GetOpenFileName() and all libs are available in "windows\system32". Is anyone can try this to confirm that it's working, thank you.
 
And, depending on how many steps it has taken the user to get up to that point in the application, they might appreciate an 'Oops go-back' to quickly and 'knowingly' get back to that point in the code.
I guess that I personally have seldom heard: "You have too many user input messages" where this sort of input is used.

I'll take the Devil's advocate role here, just because it's fun to do.

In other words, you've designed applications that box the user in to the point they're trapped if they don't do what you've decided they should do? [ponder]

A few years ago I started using an application designed by a team that had a couple of guiding principles:

[ul]
[li]If it's difficult to do, we've failed.[/li]
[li]If you're looking for something, you should find it exactly where you look for it.[/li]
[/ul]

It was a music notation application, which is an incredibly complex and arcane art. The application really was easy to use. They initially had a ton of "did you mean to do that?" dialogs, but they put "never show this again" checkboxes on each of them. They found that EVERY USER checked that box every time.

If I can prepare a Haydn Symphony for publication free from unnecessary "Are you sure?" prompts, you might want to rethink your application designs. [wink]

We overuse messagebox().
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top