On Wednesday, 13 July 2016 at 16:48:53 UTC, Adam Sansier wrote:
> There's a lot of misinformation on the net.

Nope, it's just you. COM support in D and in general works fine for everyone else.

On Wednesday, 13 July 2016 at 02:41:22 UTC, Adam Sansier wrote:
> If you can convince me to try it out, I might... but doing com isn't my primary goal here and I seem to have finished up what I was trying to achieve(my use case is probably relatively simple though). Last thing I want to do is get bogged down in this stuff, which feels clumsy and not well documented(Both the D and C sides)

Juno is definitely of more value if you're trying to access standard Windows COM objects, that way you don't have to write the interface definitions yourself.

You'd mentioned that you got it work with a hack and there should be a better way, Juno might be that better way.

It looks to me like your extern(C++) is needed because you're trying to shove the pointer from coCreateInstance into a D class. With COM you don't work with concrete classes, only interfaces. Code below is not tested and only from limited knowledge.

    IMYCASIO cASIO : IUnknown
    {
        void func1(char *name);
        void func2(int);
    }

    //...
    IMYCASIO obj;
    CoCreateInstance(..., cast(void**) &obj);

    obj.func1("me");

The only other thing I can think is, if you are obtaining an object that defines static methods, those aren't supported by COM. COM only works on virtual functions and you're probably just hacking memory address space to get at those functions.

On Wednesday, 13 July 2016 at 19:22:44 UTC, Kagamin wrote:
> On Wednesday, 13 July 2016 at 16:48:53 UTC, Adam Sansier wrote:
>> There's a lot of misinformation on the net.
>
> Nope, it's just you. COM support in D and in general works fine for everyone else.

For anyone else having similar problems please ignore. COM doesn't work perfectly regardless of what some nobody says and I'm not the only one having problems. There are others and a search shows this.

http://forum.dlang.org/thread/iovu2e$2d3d$1@digitalmars.com

I notice you are the last one to say "COM uses stdcall convention. Everything else is not COM." Spreading your lies and disinformation. People like you are a source of problems, not a solution. Please learn that you don't know everything and your generalization about how everything works is simply wrong.

http://www.digitalmars.com/d/archives/digitalmars/D/learn/thiscall_calling_convention_4943.html

Regardless of why the problems exist, or if they are subtle or only in certain scenarios, they exist and some imbecile claiming they don't just makes more trouble for those trying to solve their problems.

If you don't like my attitude, stop acting like the world is perfect and when someone has a problem that it just might be legitimate. If you don't actually feel like helping, simply don't reply, it's that easy.

On Wednesday, 13 July 2016 at 20:02:50 UTC, Jesse Phillips wrote:
> On Wednesday, 13 July 2016 at 02:41:22 UTC, Adam Sansier wrote:
>> If you can convince me to try it out, I might... but doing com isn't my primary goal here and I seem to have finished up what I was trying to achieve(my use case is probably relatively simple though). Last thing I want to do is get bogged down in this stuff, which feels clumsy and not well documented(Both the D and C sides)
>
> Juno is definitely of more value if you're trying to access standard Windows COM objects, that way you don't have to write the interface definitions yourself.
>
> You'd mentioned that you got it work with a hack and there should be a better way, Juno might be that better way.
>
> It looks to me like your extern(C++) is needed because you're trying to shove the pointer from coCreateInstance into a D class. With COM you don't work with concrete classes, only interfaces. Code below is not tested and only from limited knowledge.
>
>     IMYCASIO cASIO : IUnknown
>     {
>         void func1(char *name);
>         void func2(int);
>     }
>
>     //...
>     IMYCASIO obj;
>     CoCreateInstance(..., cast(void**) &obj);
>
>     obj.func1("me");
>
> The only other thing I can think is, if you are obtaining an object that defines static methods, those aren't supported by COM. COM only works on virtual functions and you're probably just hacking memory address space to get at those functions.

But juno wouldn't work with this then? Regardless if the "COM" interface I'm using is truly com as defined by some yet unknown standard, it is what I have to work with.

I was able to simply the code. I required marking only those functions of the interface as extern(C++), everything else is normal and simple. I was able to simply cast the ptr to the interface and it worked. The thing I tried in the first 5 mins that didn't, probably because I used extern(Windows) like some fools say *HAVE& to be used which wasted 2 days of my life(ok, only a few hours each day but still ;) chasing that rabbit, actually did work.

So, the point of this thread is simply to state for those in the future that such discrepancies do exist and are hard to figure out because there is little info on them.

This already thwarted one person:

http://forum.dlang.org/thread/iovu2e$2d3d$1@digitalmars.com

So this is a 10 year problem: 2006-2011-2016. Funny how it happens in 5 year increments. Was Kagamin in on it? Does he have some vested interest in people not getting this stuff to work? Luckily I don't listen to fools, and luckily extern(C++) was implemented since then and we now have a solution.

On Wednesday, 13 July 2016 at 20:28:40 UTC, Adam Sansier wrote:
> On Wednesday, 13 July 2016 at 19:22:44 UTC, Kagamin wrote:
>> On Wednesday, 13 July 2016 at 16:48:53 UTC, Adam Sansier wrote:
>>> There's a lot of misinformation on the net.
>>
>> Nope, it's just you. COM support in D and in general works fine for everyone else.
>
> For anyone else having similar problems please ignore. COM doesn't work perfectly regardless of what some nobody says and I'm not the only one having problems. There are others and a search shows this.
>
> http://forum.dlang.org/thread/iovu2e$2d3d$1@digitalmars.com
>
> I notice you are the last one to say "COM uses stdcall convention. Everything else is not COM." Spreading your lies and disinformation. People like you are a source of problems, not a solution. Please learn that you don't know everything and your generalization about how everything works is simply wrong.
>
> http://www.digitalmars.com/d/archives/digitalmars/D/learn/thiscall_calling_convention_4943.html
>
> Regardless of why the problems exist, or if they are subtle or only in certain scenarios, they exist and some imbecile claiming they don't just makes more trouble for those trying to solve their problems.
>
> If you don't like my attitude, stop acting like the world is perfect and when someone has a problem that it just might be legitimate. If you don't actually feel like helping, simply don't reply, it's that easy.

The problem is that ASIO deviates from the standard way of implementing COM. Other languages like Delphi expect COM to use stdcall too, so the problem is not unique to D. Putting "extern(C++):" before the interface method declarations should allow it to work...

interface IASIO : IUnknown {
  extern(C++):
  HRESULT SomeMethod();
}

On Wednesday, 13 July 2016 at 20:47:21 UTC, John wrote:
> On Wednesday, 13 July 2016 at 20:28:40 UTC, Adam Sansier wrote:
>> On Wednesday, 13 July 2016 at 19:22:44 UTC, Kagamin wrote:
>>> On Wednesday, 13 July 2016 at 16:48:53 UTC, Adam Sansier wrote:
>>>> There's a lot of misinformation on the net.
>>>
>>> Nope, it's just you. COM support in D and in general works fine for everyone else.
>>
>> For anyone else having similar problems please ignore. COM doesn't work perfectly regardless of what some nobody says and I'm not the only one having problems. There are others and a search shows this.
>>
>> http://forum.dlang.org/thread/iovu2e$2d3d$1@digitalmars.com
>>
>> I notice you are the last one to say "COM uses stdcall convention. Everything else is not COM." Spreading your lies and disinformation. People like you are a source of problems, not a solution. Please learn that you don't know everything and your generalization about how everything works is simply wrong.
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/learn/thiscall_calling_convention_4943.html
>>
>> Regardless of why the problems exist, or if they are subtle or only in certain scenarios, they exist and some imbecile claiming they don't just makes more trouble for those trying to solve their problems.
>>
>> If you don't like my attitude, stop acting like the world is perfect and when someone has a problem that it just might be legitimate. If you don't actually feel like helping, simply don't reply, it's that easy.
>
> The problem is that ASIO deviates from the standard way of implementing COM. Other languages like Delphi expect COM to use stdcall too, so the problem is not unique to D. Putting "extern(C++):" before the interface method declarations should allow it to work...
>
> interface IASIO : IUnknown {
>   extern(C++):
>   HRESULT SomeMethod();
> }

NO! If you do that then it's not COM! Put extern(Windows)! It's the only way it can work!

Yes! your right, If you were only around to tell me that in the first place! ;) Now we know. Again, as I said before, the problem is informational. Maybe because come works 99% of the time doesn't help us in the 1% if some think 99%=100%(that new math shit that's causing so many problems). I've created a big enough stink about it that anyone in the future having similar issues might be able to resolve them much quicker.

Thanks.

On Wednesday, 13 July 2016 at 21:27:29 UTC, Adam Sansier wrote:

>
> Yes! your right, If you were only around to tell me that in the first place! ;) Now we know. Again, as I said before, the problem is informational. Maybe because come works 99% of the time doesn't help us in the 1% if some think 99%=100%(that new math shit that's causing so many problems). I've created a big enough stink about it that anyone in the future having similar issues might be able to resolve them much quicker.


This demonstrates the importance of showing example code. Everyone who tried to help you in this thread was going on the assumption that you were using a library that does not deviate from standard practice. Personally, I had no idea that there were "COM" libraries that do that. When I did ask for example code, you still didn't post anything relevant, i.e. something that shows your interface declarations or how you were obtaining the COM pointer.

Generally, you want to give as much info as possible with these sorts of problems, including compiler, command line options, error messages, and anything you can think of that is relevant. That you were using ASIO should have been in your very first post. Please keep that in mind the next time you have an issue. It may save you a lot of grief.

On Wednesday, 13 July 2016 at 21:27:29 UTC, Adam Sansier wrote:
> Yes! your right, If you were only around to tell me that in the first place! ;) Now we know. Again, as I said before, the problem is informational.

We know it only after you posted links to threads with relevant info. You knew the problem is informational yet decided to conceal the relevant information and you knew it will result in a problem, so you consciously created that problem, it's not the world to blame for that. People in the treads you linked don't do such things, they easily see the details, provide relevant info, even full declaration of the interface, you don't do that, it was your decision to create that problem, it's not the world to blame for that. COM is documented, the world suggests to read docs before you get to anything or when you're in a trouble, you don't do that, and you know it leads to problems, and it's your decision to ask for those problems, that's your attitude - to create problems you suffer from, nobody else does that.

> I've created a big enough stink about it that anyone in the future having similar issues might be able to resolve them much quicker.

You only created lots of whining providing zero information about what's going on, that zero information won't help anyone.