Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Print Dialog using API
Message
 
To
30/04/2002 03:49:09
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
General information
Forum:
Visual FoxPro
Category:
Windows API functions
Miscellaneous
Thread ID:
00649502
Message ID:
00651052
Views:
35
>Hi George,
>I need to divide this message, the first part is a big problem to me. The other part - let's say I feel uncomfortable with to many kludges.
>----------------------------------------------------------------
>Important part:
>>
>>SET PRINTER TO NAME < Windows Printer Name > won't work for you?
>
>AFAIK < Windows Printer Name > must be known to me. I can get it from APRINTERS() but which one is the one the user need?
>
>I like the dialog from CommonDLG because I can adjust all printer settings and answers (even strange) to Cancel.
>
>call_CommonDLG
>SET PRINTER TO NAME Windows_Printer_Name
>
>
>is a good idea - but where I get the name of the printer I selected in CommonDlg?

You can't. APRINTERS() can provide you with the installed printers. GETPRINTER() can give you a name. The one thing that the Common Dialog ShowPrinter method won't do is return the name of the selected printer. You might be able to modify the class that calls the Save/Get file names to call the appropriate API call to get this, but I haven't tried it.

>Oh lord, all what I need is a dialog as simple as in MSWord
>- Print.Click -
>- Dialog - select printer, set printer's prop's -
>- (ok.Click -> Print) or (cancel.click -> no print)-
>
>no change of Windows default printer, no strange new form to adjust printer (like GETPRINTER()) just good old window style dialog that is the same like everywhere else in the system.
>
>--------------------------------------------------------------
>Philosophical part:

This is an issue of practicality from my POV.

>>Just one comment about what you mentioned above (for both you and the customer). After Win98 the Windows Script Host isn't optional. IOW, if you ever upgrade Windows, it's going to be there. There is nothing "evil" about it, except that some people of highly questionable ethics, have used it to create worms.
>
>Got an idea why I stuck on WIN98?
>You know 11th law? Do never update or upgrade. ::)
>
>There is no evil in weapons too. But without it is harder to kill somebody. We have those 17 dead in our scools now - The mad boy would hardly reach this goal with a kitchen knife.

Like this scenario, you can either ignore a problem or educate yourself about it and find a way to more effectively deal with it. Face it, the only sure fire, 100% certain way to keep a virus or worm off a computer is not to use one. The WSH is the symptom, not the cause. Read my article covering the Windows Script Host Postscript (click my name to find out when it appeared). I list a number of workarounds for having the WSH installed, but still having access to its functionality.

The easiest way to deal with a WSH virus spread by email, is to block any email message with an attachment that has one of the associated file extensions (vbs, vbe, js, jse). That's what my company does.

>Those people you talk about are sitting in federal offices? Or do you mean all the little things are hidden in HTLM code? There is more than a worm what can go wrong with WSH.

No

>WSH is a open door for each and everybody that need to be closed.

Block the files via the email client, simple. There are other ways, too.

All the WSH is is batch files for Windows. Certainly much more sophiscated that the old BAT files. Even a BAT could be used to complete format a hard drive without user doing anything than double clicking it. But, you can't blow away command.com, so people learned to live with it.

The thing is that the WSH can do things in a few lines that would require literally hundreds in VFP with calls to the API. Further, it can do things that you can't do from within VFP and would have to write a DLL to accomplish. It's a tool. Learn to use it, don't just ignore it.

>>
>>Basically, the choice for both you and your customer is either stick with outdated and eventually unsupported technology, or not. The WSH isn't going away anytime soon. I wrote a "Postscript" article on the original WSH series for the VFUG newsletter that appeared last year. In it, I discuss these issues and what you can do about it.
>
>If something is outdated or not is not the question of available new gadgets. It's only in our mind.
>Please understand me, it is not that I like the time before exploration of open fire, it is simply not needed yet.
>
>And if we start the "technology" debate, I know a lot of people (not me) feeling the whole idea of a foxpro database outdated because we have those SQL servers and the whole idea of a wintel PC as well...

There are pros and cons to both Fox's ISAM tables and SQL Server databases/tables. I'll agree that too often people rush to the "latest and greatest" without thinking about their needs in a practical manner. I'm sure that there were plenty of applications that got ported to SQL Server or Sybase for the wrong reasons. The same is going to happen with the Internet/Intranet. People will rush to get apps to this platform without considering whether or not it belongs there. What you'll end with when the wrong decision is made is that you'll end up with bad mainframe computing dressed in a browser.

>Foxpro is a giant on new "technology" now, we finaly got a GETDIR() dialog that gives us control over UNC resources. We can not place it on the srceen where we need it but I don't want to argue.

You had that under Win98/VFP 6.0 via the Shell.Application object's BrowseForFolder method. The Shell.Application is not part of the WSH. It's totally separate.

>We stuck on tiny 16*16*16 icons for our apps uggly as on WIN3.0 - no I feel happy with this "technology".
>
>We got new things to play with on VFP 7.0 but the fox will never learn how to react on ALT+F4 until we give some strange commands in the code. How many apps are out there without "ON SHUTDOWN"?

None of mine lack it. VFP handles some things in a high non-standard (in the Windows world) way, especially messaging. Part of it's performance abilities come from this.

>There are hundreds of things working not as appriciated under Windows in VFP - there are reasons in the way Foxpro is and probably this way is more important to us. But on some days this is not off help. ::(

One last thing. I used both Win2K Pro and Win98. By far, Win2K is more stable and a much better OS than Win98 even on a good day.
George

Ubi caritas et amor, deus ibi est
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform