Re: ftp from Access: problems

Terry Kreft wrote:
> You obviously have no idea what is meant by hardcoding, how OLE dlls
> work, the purpose of the registry or indeed much idea of professional
> programming.

I take it you found some hard-coded paths in your code, and have decided to
take your ball home from the playground. Good. That's known as getting
over yourself.



> I evidently have nothing to learn from you and you are evidently
> unwilling to learn from anyone else, so I think I'll leave your
> megalomanic self-perceived omniprescience where it belongs; flapping
> in the ether.
>
> <PLONK>

Smart move.



> BTW, for any lurkers;
> OLE compliant dlls can be installed anywhere; when they are
> registered an entry in the registry points to the correct file.

Now tell me how I can install them to different places but retain a
functional system. What's that? I can't, because the programs expect them
to be in certain, hard-coded locations? But that's "poor practice,
amateurish, unprofessional, etc etc."?



> Non-OLE compliant dlls can usually be installed anywhere in the
> application folder, the path or the system folder.

I want to put them somewhere else. You say it's unprofessional to hard-code
any file locations/paths. But I'd say 99% of programs in use look for fixed
file locations. So, either you're wrong or everyone else is.

I put my money on you being wrong.



> Registry entries are changeable by users and therefore are not
> hardcoded.

The locations of the keys are hard-coded within the hive, and most Windows
programs write keys to fixed locations, ala HKEY_LOCAL_MACHINE\SOFTWARE\.

Now what kind of incompetent, inflexible, amateur, unprofessional developer
at MS designed that?

He obviously never spoke to cdma weenie Terry Kreft.



> I don't know about you but I'm certainly not responsible for the

No, you're just responsible for your own delusions about being
"professional" while everyone else is an "amateur" who follows poor
programming practices.



> incompetence of the programmers at Oracle.

LOL!







> "DFS" <nospam@xxxxxxxx> wrote in message
> news:mPspf.13449$Eu3.11854@xxxxxxxxxxx
>> Terry Kreft wrote:
>>> Wrong.
>>>
>>> Wrong again.
>>>
>>> I will admit to one thing and that's not having some magical ability
>>> to read your code or know what you've written in the past. Your
>>> assertion that you are 100% certain that you know my code just seems
>>> to point to an overweaning arogance, well I hope that's all it is
>>> anyway.
>>
>> Not arrogance. It's just common knowledge that somewhere you've
>> hard-coded
>> a path to a file or an .mdb. It's no crime. But hypocrisy and
>> calling someone lazy for doing what you yourself do is.
>>
>> The routine in which I now hard-code "C:\Windows\System32\ftp -s..."
>> has at
>> least 10 statements where I employ a user-defined path, such as:
>>
>> AppDir = DLookup("LogLocal", "TBL_SETTINGS")
>> NetDir = DLookup("LogServer", "TBL_SETTINGS")
>> Open (AppDir & syncFileName) For Output As exportFile
>> FileCopy (AppDir & syncFileName), (NetDir & syncFileName)
>> If (FileLen(AppDir & syncFileName) = 0 ...
>>
>> But near the end it has two hardcoded paths which the users don't and
>> can't
>> change:
>>
>> Open "D:\upload.txt" For Output As #1
>> Shell "C:\WINDOWS\System32\ftp -s:D:\upload.txt"
>>
>> I hope you haven't billed your clients all that time you've wasted
>> making your systems unnecessarily "generic and flexible". Imagine
>> if Microsoft tried to do something similar by letting the user
>> choose where every .dll is
>> installed. They would never get a product out the door.
>>
>> And how about that "unprofessional, inflexible, lazy" Registry and
>> all those
>> hard-coded hives and keys that the OS and most Windows programs use?
>>
>> And that pesky tnsnames file Oracle requires in the <Oracle
>> home>\network\admin folder? Why can't I just move it to my desktop?
>>
>> Are the MS and Oracle people amateur developers like you accused me
>> of being?
>>
>> Like I said, get over yourself.
>>
>>
>>
>>
>>
>>>
>>>
>>> "DFS" <nospam@xxxxxxxx> wrote in message
>>> news:_p0pf.3676$It6.1294@xxxxxxxxxxx
>>>> Terry Kreft wrote:
>>>>> I have clients using Win98 and I cerainly have clients using
>>>>> WinNT.
>>>>>
>>>>> Hard coding paths
>>>>> Never in production work, concept and testing maybe it depends on
>>>>> how trivial it is.
>>>>>
>>>>> Accusing me of lying though, pretty much sums up your attitude
>>>>
>>>> I'm 100% sure you have some hard-coded paths or
>>>> values out there in your code somewhere,
>>> <SNIP
>>>>
>>> <SNIP>
>>>> But the fact is, you can't live up to your own standards.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> "DFS" <nospam@xxxxxxxx> wrote in message
>>>>> news:tLVof.17778$tQ7.15105@xxxxxxxxxxx
>>>>>> Terry Kreft wrote:
>>>>>>> In the business world operating systems do not tend to get
>>>>>>> upgraded until the decision to do so is forced.
>>>>>>
>>>>>> You have clients still running NT on the desktop?
>>>>>>
>>>>>>
>>>>>>> I spend a lot of time considering how to make my code generic
>>>>>>> and flexible simply because there are a lot of systems out
>>>>>>> there which are not standard installs, also there is nothing
>>>>>>> more likely to generate contempt from professional developers
>>>>>>> than to find a system with hardcoded paths in it.
>>>>>>>
>>>>>>> If you want to create inflexible code then that's entirely up to
>>>>>>> you, but please don't pretend that there is any value to doing
>>>>>>> this except that it allows you to be lazy.
>>>>>>
>>>>>> If you're telling me you have no hard-coded paths in any of your
>>>>>> code, I'd
>>>>>> say... you're a liar.
>>>>>>
>>>>>> Get over yourself.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> "DFS" <nospam@xxxxxxxx> wrote in message
>>>>>>> news:C9Pof.6813$Xx3.5523@xxxxxxxxxxx
>>>>>>>> Tom van Stiphout wrote:
>>>>>>>>> On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
>>>>>>>>> <terry.kreft@xxxxxxxxx> wrote:
>>>>>>>>>
>>>>>>>>> But it's somewhat reasonable to assume ftp.exe is installed in
>>>>>>>>> the system32 folder, which by default is in the path. Actually
>>>>>>>>> the use of ComSpec assumes that as well. So one might write:
>>>>>>>>> Shell "ftp.exe -s:D:\upload.txt"
>>>>>>>>
>>>>>>>>
>>>>>>>> That doesn't work - at least on my WinServer system. That's
>>>>>>>> what prompted my initial post.
>>>>>>>>
>>>>>>>> I had to specify C:\Windows\System32\ftp, and it runs fine.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Tom.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Nope that''s bad advice there are a whole host of systems
>>>>>>>>>> I've seen where windows is installed in the folder WinNT
>>>>>>>>>> rather than Windows.
>>>>>>>>
>>>>>>>> Hmmm... sounds ancient.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> It's poor practice to hard code variables when there is a way
>>>>>>>>>> to getthe value dynamically anyway.
>>>>>>>>
>>>>>>>> Probably, but the client machine uses C:\Windows\System32. So
>>>>>>>> does 100% of
>>>>>>>> standard XP and Server 2003 installs.



.

Relevant Pages

  • Re: ftp from Access: problems
    ... You obviously have no idea what is meant by hardcoding, how OLE dlls work, ... the purpose of the registry or indeed much idea of professional programming. ...
    (comp.databases.ms-access)
  • "APPINIT_DLLS=" error and ".wll" error
    ... Ok first off I have no knowledge of registry problems or how to fix them. ... All the DLLs that are specified in this value are loaded by each Microsoft ... Note This feature may not be available in future versions of the Windows ... Microsoft Windows 2000 Standard Edition ...
    (microsoft.public.windowsupdate)
  • Help!: Problems with Restricted access accounts
    ... series of business object DLLs that need to be registered on each local ... Our clients have their users set up as Restricted user accounts. ... the user tries again as a restricted access user account, ... seems that the user is unable to "see" the DLL entries in the registry. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: How to work around UAC?
    ... In these situations, and with UAC active, our DLLs no longer ... have access to our software's registry keys. ... your DLLs DO have access to HKLM - but read only. ...
    (microsoft.public.platformsdk.security)
  • Logon Problem
    ... EXPLORER.EXE (and a few DLLs) some time ago. ... be a prankster (not a virus) is having fun at your expense. ... >other things in the registry. ... >the run and the run once keys to ensure that no seemingly ...
    (microsoft.public.windowsxp.general)