How to download a file from the internet? [SOLVED]
-
On 07/10/2014 at 12:50, xxxxxxxx wrote:
Thank you, MohamedSakr.
I did found it online.
Ok, now Cinema 4D starts without errors. But my plugin doesn't even start.
I placed GePrint's all over the place, mainly in the main.cpp, even before calling all my serialization stuff and nothing gets printed in the Console. -
On 07/10/2014 at 12:53, xxxxxxxx wrote:
this needs code revision
, test it in a step by step way, so GePrint in the plugin init function to check, test print after every line, till you find which line stops the plugin -
On 07/10/2014 at 12:55, xxxxxxxx wrote:
a better approach "but in your case this will look much harder" , compile in "debug" , and step by step, this will need you to learn how debugging work in C++ "and specially in Visual Studio"
-
On 07/10/2014 at 13:31, xxxxxxxx wrote:
Well, I did found out how to debug in Xcode. It is quite simple.
But, in Visual Studio, everything is so much more complex. No auto-completion, no warnings as I type, no suggestions, cryptic errors messages, etc.
I guess I will the GePrint method first, to test out everything. -
On 17/10/2014 at 13:00, xxxxxxxx wrote:
Hi guys,
I see you're having some difficulty with the Windows specific software development environment. Although I'm a bit surprised there doesn't seem to be the equivalent problem on Macs, I'll try to clear it up:
At a high level, consider 32 bit vs. 64 bit, release vs. debug. Multiply them out to get four target combinations. For instance, using "32 bit release compiled, dynamically linked 3rd party SDK files" means you have to copy the 32 bit release DLLs from the 3rd party SDK's file set into the C4D directory that you copy your dependent plugin files. If you instead copy any of the debug DLLs, or the 64 bit release DLLs, it won't work. You can't mix 32 and 64 bit code, they're different platforms, meaning the instruction sets are noticeably different. The files across the four combinations generally won't compile together, link together, nor run mixed up together.
Note: you may hear of some Frankenstein situations, especially mixing release and debug, but they come along with maintenance problems and have major limitations.
So the valid standard combos are:
32 bit debug
32 bit release
64 bit debug
64 bit releaseStatic vs. dynamic
Static linking means the library's code is embedded into your executable. You pay a price by bloating your executable, among other things, and is only a good idea in limited situations.
In contrast, dynamic linking means your executable is setup by the linker to seek out and load one or more separate files (DLLs) when executed, and those DLLs will seek out DLLs they are dependent on, and so on, until all required files are loaded. The catch is that Windows will only look in certain directories, not search across your entire hard disk (or beyond) for them (the rules for the search are explained in MSDN). The most reliable and straightforward way to make sure it can find them is to include them alongside your C4D plugin executable. This is when you must also align the 32 / 64, release / debug factors to copy the right version of the DLLs. Any mismatch will lead to failed execution or similar grief.
The only other factors that you can add per category (or create additional categories) is when you start mixing compilers (ex: Microsoft / Intel), hybrid targets (release with selective debug executables), etc. However, that's when you multiple out the pain of maintaining all the compilation/link target combinations. Of course, you can't escape versioning, but you usually control the SDK upgrade and maintain the same targets.
A big exception is made for Microsoft's runtime DLLs: you have to install them from the correct VC redistributable for each target. Again, 32 / 64, release / debug, and their specific versions are all factors, with the added complication that they purposefully don't create debug redistributable installers. You must install the compiler to get them on a system, copy them manually alongside your executable (ugly / brute force), or create an installer from them yourself (advanced topic, best you look it up if you REALLY need to go there).
As for the nitty gritty details and comparisons (advantages vs. disadvantages of static vs. dynamic), I suggest you read the Wikipedia entries, as it would be too long to summarize here.
My 2 cents,
Joey Gaspe
SDK Support -
On 18/10/2014 at 03:43, xxxxxxxx wrote:
Thank you for the very informative post, Joey.
I'm still struggling with this, on Windows (I repeat... it is so much easier on Mac OS)
I don't mind bloating my code but I really would like to embed all the code necessary. I was told that WinInet would be able to use the .dll files that are already included in Windows.
But I still have to find a way to use WinInet. -
On 20/10/2014 at 11:35, xxxxxxxx wrote:
Hi Rui,
Thanks for letting me know, we're trying our best to guide you guys in the right direction. When you use languages like C/C++, you're automatically going into the 'advanced' / 'hardcore' areas of software development. Combine that with plugin development, and you're going into an area only few dare venture.
As for Windows specific issues, various Microsoft related 'policies' create these situations for which you must be very much aware of multiple factors that you clearly don't have on Mac OS X. The 32 / 64 bit issue is due to prioritizing backward compatibility over simplicity, and most of the rest is to provide power and choice, much like why C/C++ are hard to learn and use. All I can say is don't give up, and we're here to help. Also, the best explanations aren't on the Internet, they're found in books (if anywhere)... That's why software devs have big personal libraries, and yet they'll tell you they're still missing some on the latest topics!
As for WinInet, sorry, but that's very far from the scope of coverage on the Plugin Cafe SDK Support for Cinema 4D. There seems to be a few good books about the subject, and you can get started on MSDN. Internet communications programming is definitely a big topic.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa385331(v=vs.85).aspx
I hope that helps,
Joey
-
On 23/03/2015 at 05:32, xxxxxxxx wrote:
Hi Scott,
Originally posted by xxxxxxxx
Installation instructions///////////////////////////////////////////////////////////////////////////////////////////////////////////
-Unzip to c:\curl
-Build curl to generate the .dll and .lib files needed, I used this in the VC console to build it: nmake /f Makefile.vc mode=dll
-Set up VS to use them:
Put libcurl.lib in the Linker->Input "Additional Dependencies" top window
Put C:\curl\builds\libcurl-vc-x86-release-dll-ipv6-sspi-winssl\include\curl in "Include Directories"
Put C:\curl\builds\libcurl-vc-x86-release-dll-ipv6-sspi-winssl\lib in "Library Directories"//////////////////////////////////////////////////////////////////////////////////////////////////////////////[/ CODE]Do you know how to, or what to do, to add something like this using it's complete source files? I can't stand the whole MinGW and command line build rubbish. I'd rather just add the plain complete source files. But they never seem to come with just that?
I'm needing a download process in my plugin and came across curl like Rui, and thought I'd use this as an experiment on creating the following:
I'd like to try make a single header which contains all the define's needed for the thing to work, cross-platform, with something like the following:
// Single Curly.h header file
#ifndef __MY_CURLY_H
#define __MY_CURLY_H#include <curl.h>
ifndef "pc"
...etc...
elifdef "mac"
...etc......anything else important here etc...
#endif
I then want to use this header in the plugin's MyPlugin.cpp file, so that there's an easy move-over between the two different platforms withouthaving to deal with the library rubbish. The size of the resulting plugin is irrelevant, so building the complete curl system into the plugin is fine.
Do you know how to setup something like this? Or have you been able to do this with something similar before? Or is there no way to avoid MinGW and the likes?
WP.
EDIT: this forum has a hopeless way of dealing with the code brackets! Double lines, messed up new lines... I've edited Scott's partial quote above to resemble the posted original.
-
On 07/07/2015 at 02:31, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Damn!! It is soooo easy in python.
How come it is something so complicated in C++?It's only so easy in Python because the Python developers have already done all the tedious C work for you
-
On 07/07/2015 at 15:28, xxxxxxxx wrote:
Yes, I understand that.
And I did managed to make it work on Mac OS X, in C++
But not in Windows. Windows makes it all so much more complicated
-
On 26/01/2016 at 05:36, xxxxxxxx wrote:
Hi Rui,
could you please share the way you have implemented the internet access on Mac OS X? For me, it's exactly reverse. On the Mac things are complicated, that are easy in Windows. So, it's a matter of practice, I think.