|
The Excel object should be referenced in your project. Try looking up MS Office Interop.
|
|
|
|
|
Hello again
I've a textbox where i write the name of a file or a folder to check
to check a foder I've a function and to check a file I've another function
how to distinct if the user write the name of a foder or a file to tell the programe which function to check
thanks in advance
Assaf
|
|
|
|
|
Using just what the user typed in the TextBox, you can't. How about trying BOTH functions, with proper result handling, and seeing which function says the entered name exists?
|
|
|
|
|
each function give a message tell me the result
but i try to avoud having to message box
if there other way please tell me
Assaf
|
|
|
|
|
It's not a matter of a function giving you what you want. It's your logic that's flawed here. Your methods that check for the existance of a folder or file should just return a Boolean. They shouldn't put up a MessageBox at all.
Think about it. You call both functions with the same name. If they both return false, then the entered name doesn't exist as either a file or a folder. If one of them returns true, then I guess you've found out which it is. If they both return true, you've seriously messed up your checking code in one or both of your methods.
|
|
|
|
|
Hello
how i can check if a specific foder exist or not
folder and not a file
Thanks in advance
Assaf
|
|
|
|
|
I get it
directoryInfo
Stupid question i know
Assaf
|
|
|
|
|
Hi!
I have compiled a DLL in C++ (on WinXP) and I need to use it in Visual Basic (actually, in VBA included in Excel).
I have used the following declare command in Excel VBA:
Public Declare Function apSimulator Lib _
"C:\Econoblast++\PricerLibrary.dll" Alias "_Simulator_average_performance@72" _
( ... arguments...) As Double
1) On the machine I have used to build my DLL, everything is OK: VBA correctly calls the DLL (finds its entry point and matches its calling convenctions,etc...). 
2) If I change DLL name or extension, for instance from .dll to .dol, if I change path in Declare command, everything is still Ok.
3) When copy my *.xls and *.dll file on onother machine, VBA returns run-time error #48: It Can't find the file. 
EVEN THOUGH THE FILE REALLY EXISTS, AND ITS FULLY QUALIFIED PATH IS OK!!
What does it mean????? 
Should I "register" my dll? The test of point 2) should mean I don't have to, doesn't it?
On every machine different from the one I used to build the DLL, or at least on the once I tested, VBA returns error 48.
Plz, HELP ME!!!
|
|
|
|
|
I think, but am not sure, when you compile a DLL, the system automatically registers it.
Try unregistering it on my development machine and try VBA again.
Then, register it on the non-development machine and try VBA.
Post the results.
Tim
|
|
|
|
|
Read my next answer. Actually, my dll seems not to be registered (because it has not to be registered).
|
|
|
|
|
Registering the .DLL only works if you've written a COM dll. If not, then you'll get an error message when you try and register it.
Other than that, you're best solution is to NOT include the full path to the .DLL in your code, but just mention the .DLL name. Then, you put the .DLL file you're using in the same folder as your .EXE.
Public Declare Function apSimulator Lib "PricerLibrary.dll" _
Alias "_Simulator_average_performance" (...arguments...) As Double
Did you really called the function in your DLL code "_Simulator_average_performance"??
|
|
|
|
|
Ok, it is not a Com DLL and if I attempt to register it I get and error, indeed. Neither I can unregister it, of course (I tried to, but I get the same error). So "registering DLL" shouldn't be the right way.
I tried to use a relative path, but it doesn't work anyway!!!
What can it be?? 
Er.. actually my DLL function name is
_Simulator_average_performance@74
(I forgot a "@74" in previous message, but not in the code, of course )
This because I couldn't manage to export the function name "Simulator_average_performance" without those silly decoration imposed by __stdcall... but this is another matter.
My problem seems to be a NONSENSE
Plz, help me in debugging....
|
|
|
|
|
Capitanevs wrote: Er.. actually my DLL function name is
_Simulator_average_performance@74
(I forgot a "@74" in previous message, but not in the code, of course )
The reason why the compiler "decorated" the names is for type safety.
You cannot use the "@74" in the alias name. You can use either the function name (undecorated), or use its oridnal number. To use the ordinal, your declare would look something like this:
Public Declare Function apSimulator Lib "PricerLibrary.dll" _
Alias "#74" ( ... arguments...) As Double
|
|
|
|
|
Are you sure?
I have used like I wrote and I used to work (until it stopped, at least... )
I mean, if I use dependencies viewer to inspect my dll a function named
_FunctionName@74 appears in the function list. So I expect "_FunctionName@74" to be the effective name whom the DLL function is seen with bt an external caller.
What is an ordinal?
|
|
|
|
|
The ordinal is a number used to reference the function name if you don't have the name, or can't use it. In "Depends", it's listed right next to the function name.
|
|
|
|
|
|
Capitanevs wrote: 2) My DLL doesn't depend dynamically on anything. I had to use an external precompiled library, but It should be embedded in the code, shouldn't it?
If it's statically linked, yes. If not (default), no. The libraries are seperate.
Which version of C++ did you use to compile this .DLL?? Are the correct version of the runtime libraries installed on the target machine??
|
|
|
|
|
I used Visual C++ 2008 Express Edition.
What do you mean with "runtime libraries" ?
Why a DLL built in C++ needs runtime libraries? This happens with every compiler or only with Microsoft ones?
I inspected dependencies of my DLL and I found two DLL
MSVCP90.dll
MSVCR90.DLL
that I have only on my dev-machine. Do you think this is the point?
I tried to copy them in \system32\ or in \appfolder\, tried to register them (but they probably needn't to), but on the generic-machine my DLL still doesn't work.
Do you think I should post this topic on the VC++ forum?
Finally, we seem to have shown that it is a VC rather than VB matter.. 
|
|
|
|
|
Capitanevs wrote: What do you mean with "runtime libraries" ?
Why a DLL built in C++ needs runtime libraries? This happens with every compiler or only with Microsoft ones?
This happens with every compiler. Yes, you need the libraries. The compiler doesn't automagically know how what is needed to get code running, nor does it know how all of those function calls you made work, nor does it know what those functions are or what they're return values are supposed to be, ... This is where those libraries come in. Instead of putting all that extra code (you didn't write) into your binary, the compiler puts in "imports", or what your code needs from the outside world in order to get at those functions you're calling.
Capitanevs wrote: I inspected dependencies of my DLL and I found two DLL
MSVCP90.dll
MSVCR90.DLL
that I have only on my dev-machine. Do you think this is the point?
Yep.
<blockquote class="FQ"><div class="FQA">Capitanevs wrote:</div>I tried to copy them in \system32\ or in \appfolder\, tried to register them (but they probably needn't to), but on the generic-machine my DLL still doesn't work.</blockquote>
That's because you can't get away with doing that. Those libraries have dependancies of their own. You have to install the runtime package on the target machine in order to get it to work.
Get it here[^].
|
|
|
|
|
Wait! You upset me!
I mean, I expected that C/C++ compilers built an EXE or a LIB without
any particular library, 'cuz the program is compiled in machine code.
On the contrary, I knew that VB needed its
runtime libraries because EXE created with VB aren't "really compiled",
but need to be interpreted by an external server.
I built a simple "Hello world" C++ program with MS Visual Studio and
with DEV-C++ (using g++ compiler).
The result is that the first one depends on MSVC9 libraries and DOESN'T
work on the other machines, but the second one (which doesn't depend on
MSVC9 dlls) correctly runs everywhere...
Cannot I make a DLL-independent EXE with Visual Studio? It must be possbile!!! 
|
|
|
|
|
Capitanevs wrote: I mean, I expected that C/C++ compilers built an EXE or a LIB without
any particular library, 'cuz the program is compiled in machine code.
Partially true. Code is compiled into native code modules that are linked together, either by stitching modules together into the .EXE or .DLL or by including external import table entries that load and call into external modules (library .DLL's) at runtime.
Capitanevs wrote: On the contrary, I knew that VB needed its
runtime libraries because EXE created with VB aren't "really compiled",
Yes they are. For VB6 and below, the code is compiled into native code, but with a bunch more imports of external library calls. For any language targeting the .NET CLR, code is compiled into a CPU-agnostic "middle" language, called MS intermidiate Language (MSIL), whcih is then compiled into native machine code on-demand, at runtime. But, the library import process is approximately the same.
Capitanevs wrote: I built a simple "Hello world" C++ program with MS Visual Studio and
with DEV-C++ (using g++ compiler).
The result is that the first one depends on MSVC9 libraries and DOESN'T
work on the other machines, but the second one (which doesn't depend on
MSVC9 dlls) correctly runs everywhere...
Cannot I make a DLL-independent EXE with Visual Studio? It must be possbile!!!
No, it's not. Every version of the .EXE or .DLL you make depends on the VC runtime libraries. It's just that some versions of the libraries come preinstalled in Windows, while other versions are installed by other applications when they're installed. This is why you seem to think that a version of your .EXE/.DLL doesn't require the runtimes. They do need them. It's just that they're already installed for you by something else.
If you made an installer for your application or .DLL, you'd have to include the runtime libraries in your installer.
|
|
|
|
|
Ok tnx!
I have worked out the matter.
VS2008 dynamically links to runtime libraries (vs98 dind't), and this confused me a bit.
Now it's all ok, as I was told how to force statical link of libraries.
Thank you a lot!
Michele
|
|
|
|
|
I'm a bit confused and thou made me upset...
I compiled a C-"Hello World" and a C++"Hello world" using MS VC++ 2008 Express edition default release settings.
Inspecting, I noticed that both of them depend on some kind of "Runtime Libraries" you told.
They are MSVC90R.DLL for pure C EXE and MSVC90R.DLL plus
MSCVP90DLL for C++ EXE.
I compiled the same sources with gcc/g++ compilers and, of course, there are no dependencies on external DLL.
I compiled the sourcers with my old VC++ compiler (Visual Studio 6, professional edition) and, again, I found
no dependencies on external DLL.
So
1) Why Ms decided to make EXE files DLL-dependent as default setting? Shouldn't C/C++ produce an executable the
most library-free as it can?
2) How can I avoid this? As I expect I CAN produce an executable which doesn't need VC2008 runtime libraries...can't I?
|
|
|
|
|
Capitanevs wrote: I compiled the same sources with gcc/g++ compilers and, of course, there are no dependencies on external DLL.
There are two ways to link an .EXE/.DLL together. One is to reduce the size of your final .EXE/.DLL by including all external code dependancies as imports from external libraries (dynamic linking.) The other is to sacrifice image size by including the actual code from the external libraries in your final .EXE/.DLL, thereby avoiding the imports (static linking.)
The downside to static linking is the greatly increased size of the final binary file as you've just included the minimum runtime and and external function calls into your code.
Some compilers/linkers setup static linking as default and some default to dynamic linking. MS preferes dynamic linking to reduce binary file size and decrease load times.
Capitanevs wrote: 2) How can I avoid this? As I expect I CAN produce an executable which doesn't need VC2008 runtime libraries...can't I?
You can't. Your code will always have the dependancies. It's just a matter of how you want to link the code together and what price you want to pay. If you want the external code linked into your.EXE, you'll pay for it with a much larger executable size. If you want a smaller file, you put up with installing the runtime libraries seperately.
No matter what compiler you use, you will always have external library dependancies. Even your gcc compiler uses runtime libraries. it's just that those external references have been resolved by copying the code from those libraries into your final .EXE/.DLL.
|
|
|
|
|
hey !
i want to write a program with out using dll file ..
i need the read, write and append functions :
and also plz tell how to check the file is already existing
with a eg 
thx!
with regards!
varun
If I have seen further it is by standing on the shoulders of giants.
Isaac Newton, Letter to Robert Hooke, February 5, 1675
The key is always be open to learn from youngs or elders.
i know a little want to know lot more 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
