Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ c++ support
c++ support

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 3  4  5  6  

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #15 on Mon 01 Mar 2004 02:21 AM (UTC)

Amended on Mon 01 Mar 2004 02:24 AM (UTC) by Shadowfyr

Message
Hmm. Practically the first page of the manual nukes the idea of employing this. Basically you have 4 ways to link stuff into your program:

1. Code it directly.
2. Use a DLL, without any ActiveX support.
3. Use a DLL/EXE that has an imbedded table and supports the IUnknown interface.
4. Use a DLL/EXE that has an imbedded table and supports the IUnknown and Windows Scripting interfaces.

CSL is type 2, which means you have to directly link it into your program to use it. This is only one step above coding the entire thing yourself, in terms of the inflexibility and usefulness of it to us.

Type 3 ones, which are fairly easy to code are what most things, like databases and our mini-programs are built on. They can provide a program that wants to use them with a way to ask the DLL or EXE if it can do some task. Basically something like:

MyObject.QueryInterface("Picture", ...)

would ask myObject if it supported the interface for setting a picture. This makes it possible to either get a complete list of things it supports (using a different and slightly more annoying method) or attempting to use a command and having the control tell you if it would work. Example:

MyControl v1.0 - Supports Picture
MyControl v2.0 - Supports Picture, Picture2
MyControl v3.0 - Supports Picture, Picture2, Picture2

Maybe the first version only supported B&W, the next was 256 colors and the last is 32-bit. Your program and attempt to use Picture3, but if unable to (you have the wrong version), you can then try Picture2, then Picture1. Your program will thus still work, even if the version of the control is an old one. Or you can just have it scream that you need to upgrade.

Anyway.. Type 4, which implements the Active Script system needs to have IUnknown, so your program can ask if it supports some needed functions to be used in scripting. These are absolutely needed, since they include the methods needed to tell Mushclient when the script is done running code, let Mushclient call subs and functions in the script itself, etc. IE also used this interface to link things like buttons and stuff that it is displaying to the script, so when you click the button, it runs part of the script. Most scripts can't do this themselves, even if they do create the button itself.

The problem is that like virtually every actually *useful* piece of information, examples and explainations of the interface need for Active Scripting is probably buried someplace no one has a clue to look, or only comes with the super-professional-ultra-expensive-you'll-have-to-sell-your-sole-to-afford-this version of your favorite MS compiler. I certainly haven't had much luck finding usable information on it anyplace.

To use CSL with Mushclient, someone will need to build an Active Scripting 'wrapper' around the CSL code that provides the needed interfaces. :(
Top
Posted by Dubthach   (47 posts)  Bio
Date Reply #16 on Tue 02 Mar 2004 12:43 AM (UTC)
Message
Couple times in this thread I've seen Java and JavaScript compared as if JavaScript is some kind of "light" Java scripting language. JavaScript and Java are not related except in that they both have a C-like syntax.
Top
Posted by Seawolf   USA  (57 posts)  Bio
Date Reply #17 on Tue 30 Mar 2004 04:23 PM (UTC)
Message
so while I'm being a clueless user, where would .net type stuff fit in there <g>

run away! a clueless user has entered the conversation!

i need more sleep
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #18 on Tue 30 Mar 2004 11:56 PM (UTC)
Message
Prior to .NET, Visual Basic, Java and other things all used individual libraries. In other words, if you had a Java application it would need some file called Javarun.dll or something (I have no clue what it may be called). If you wrote a VB program, then it would need a file called vbrun300.dll or vbrun400.dll, or vbrun600.dll, etc. Each vbrun???.dll is a library that provides all the special gadgets that Visual Basic programs need to work, since they use pre-built 'libraries', instead of having the used design everything from the ground up.

The problem was that a) these where extra files you had to install to use anything, b) different versions where needed, depending on what version of VB they wrote it in, c) the libraries took up extra space in installation files that wasn;t always needed. Also, there was a completely different set of gadgets for VB, another for Java, another for C++, another for....

.NET was designed to solve this by providing a *single library* that all languages use. In theory, once installed, you never need to install a new version of those dlls to fix something that won't run (knowing Microsoft, this is probably not accurate... lol).

Basically.. It probably doesn't effect scripts, may effect how programs are written that are called through the script (since the original ActiveX COM has been replaced with COM+ in .NET) and the odds are about 50/50 whether or not it helps or hinders designing new programs to be used with Mushclient.
Top
Posted by Seawolf   USA  (57 posts)  Bio
Date Reply #19 on Wed 31 Mar 2004 04:39 AM (UTC)
Message
Well, thanks for the info.

I really like what I've seen of .NET (and now this XNA initiative sounds rockin too)

And yes, before you ask, I am usually labelled a Microsoft fanatic.

Although I ask who put a tic in my fan ;)
Top
Posted by Seawolf   USA  (57 posts)  Bio
Date Reply #20 on Mon 17 May 2004 10:31 PM (UTC)
Message
So hey Nick...while I'm wasting (everyones) time...what do you think of .net and C# and all that?
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #21 on Mon 17 May 2004 10:37 PM (UTC)
Message
In what context?

I think that C# is a cool gadget for writing plugins to MS applications (addins for office, etc.) Its platform- and Microsoft-dependency however makes me not want to spend too much time with it. It all depends on what the context of your question is.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Seawolf   USA  (57 posts)  Bio
Date Reply #22 on Tue 18 May 2004 03:23 AM (UTC)
Message
Well, for telnet apps is more the context of my question...and heck, most apps are Windows only anyway

Of course, there's the Mono project which just went beta, if you want to use .net in linux
Top
Posted by Seawolf   USA  (57 posts)  Bio
Date Reply #23 on Tue 18 May 2004 03:23 AM (UTC)
Message
Err, not just telnet I guess, but it was in regards to MUSHclient type apps
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #24 on Tue 18 May 2004 03:29 AM (UTC)
Message
Well Seawolf.. .NET completely changed the underlying architecture of the languages in some ways. One of these adjustments basically means that creating certain types of custom COM objects, like user controls, no longer works the same way or can actually be impossible to do. A lot of stuff you could do in VB 6.0 you can't duplicate in VB.NET because of it. Since COM is involved in these changes, it could concievably have a serious negative impact on designing programs and objects for use with Mushclient. Personally.. I have enough problems trying to adress 'basic' functionality in the existing VB, which involves simple things like, "gasp!", actually figuring out what the dimensions of a frames client area is at any given moment, without fighting the .NET system over even more things they left out of the new version of VB because of it.

Microsoft's trend in languages is much the same as in the OS, simplify the task of the end user, by streamlining tasks and making it easier to just plug parts into each other like a lego set. Unfortunately, if you ever played with legos, then you should recognize the side effect of this trend, the greater an greater reliance on big, prefab parts that look nice, but only let you build the model on the outside of the box. This is in contrast to the early days, when just building the spaceship or castle using the instructions was far more complex, but you could use all the smaller parts to build nearly anything you could imagine.

The newest trend around the corner for MS is not only to obfuscate the level of control you have in C# compared to what may have been possible in C++, but actually introducing something called XAML, which will let you design software like a web page. It appears that this is, at compile time, converted into C# instructions, which then get compiled. This is technically a good thing, since it makes designing simple programs easier, but it has two other effects - It lets MS dictate the interface, since 'their' decoder will decide what the C# code actually does and it could potentially seperate the coder even farther away from the ability to actually *code* anything.

The problem is that MS doesn't generally do this by adding an optional 'layer' in between the actually compiler and the code. It makes the whole process dependent on what 'they' think 'we' want or need. I would personally prefer if they started listening to what we want and need, not try to convince us that they know best. A complaint that is quite common among a lot of designers, who all complain that the only users MS pays any attention to are the majority of dumber users that think that a compiler in someone that stacks computers, rather than paying attention to the people that actually have a clue what tools are needed.

So.. From what I have heard:

Good things:

A single library instead of a mess of different ones.

Bad things:

Event less functionality in some cases.
Loss of existing functionality.
No fixes for existing problems that are already making desing difficult.

But heck.. I could be completely wrong, but past experience, things I have heard and the fact that the last 'simple' project in VB 6.0 required a week of hunting and help from several forums to get working 90% of the way I intended, all tend to make me suspicious of any great improvements in my ability to actually design anything *my way* in .NET. lol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #25 on Tue 18 May 2004 03:36 AM (UTC)
Message
VB.Net is a different language and the .NET platform if very different. You shouldn't have expected your VB apps to just pick up and move to VB.net without changes.

If you think there is less functionality, then I'm willing to bet a lot of money on the fact that you're not using it right. One could argue that perhaps some things shouldn't be so hard, but that's another topic.

Quote:
'their' decoder will decide what the C# code actually does and it could potentially seperate the coder even farther away from the ability to actually *code* anything.


Why is this a bad thing? There are many, many people who say that if all you have to deal with is high-level constructs, and no longer any low-level stuff, you lose a lot of hassle and can focus on solving a problem. Isn't that what VB is all about? This is only taking that same idea further. I'm surprised that you like VB but you don't like the idea of simplified programming.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #26 on Tue 18 May 2004 04:29 AM (UTC)
Message
Umm.. I am not using .NET at all. You can't simply shoehorn it into VB 6.0 and despite MS' apparently belief to the contrary, I don't have hundreds of dollars to upgrade every time they come out with a new compiler.

As for the comment about high level stuff... I have no problem with high level languages, they are very nice and make things a lot easier. My problem is that Microsoft's tradition with high level stuff is that the more easy to use and high level it gets, the less low level stuff you can even do at all. You see this in the OS, where under XP you either need a 3rd. party tool that basically does registry hacks or hack it yourself to make changes to some basic options that you could easilly tweak under 98 or even NT. It is about choice. VC++ was complicated, then came VB, where they took away the 'choice' to even do some things, but you could hand code User32.dll calls for 'some' things in and get around some limits. Now you have .NET, which not only, do to the changes in design, removes some options, it also seperates the coder even further from the option to do some things.

XAML seperates you even farther. The problem is that the page I saw showed XAML code and then "here is the equivalent C# code". This either means that it 'replaces' the function of a compiler or it translates 'to' C#. If the second is true, then you only have to deal with the limitations of C#. If instead it is really designed to be a completely seperate architecture, then once again, you lose any and all choice in what you can or can't do and on what level. And I don't know about you, but if I have trouble buying VB.NET, then having to run out an buy C#, VB.NET and some product that uses XAML, because I can't do anything really simple in C# or VB, but XAML is too limited, but again, I still can't do some things in VB at all, then...

Right now one project I want to do is hung up simply because a 'basic' funtion of the base frames used for all windows is not merely unavailable directly from VB, but because there isn't even an API you can use to access that level of function. MS never bothered to design one, since the only place 'they' use it is by reading the value, or within their *own* form designers. If there was an API for it, then anyone could write a non-MS approved language, complete with a full IDE that includes full support for design and runtime modes for objects. The solution... Spend weeks looking for a decent example of how it works and find almost nothing, or pay some other 3rd party for a $500 designer that you can't use anyway. Gee... Great choice.. But the fact is, MS provides virtually no documentation on using Ambient values, other than determining their current state. Even making them work in VC++ is such an insanely convoluted mess that just the macros used seem to span 5-6 different headers. They really don't seem to want anyone to know how to actually set them. This isn't low level machine language stuff, it is a *basic* property of all windows.

So, even in VC++, they intentionally leave out key documentation and obfuscate the operation of some things so you can't use them without wasting a lot of time and effort. This doesn't, as someone used to having the 'option' of using lower level things when needed, particularly impress me about MS compilers, or any of their other software for that matter.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #27 on Tue 18 May 2004 05:59 AM (UTC)
Message
What exactly is it that you're so unable to find?

Quote:
My problem is that Microsoft's tradition with high level stuff is that the more easy to use and high level it gets, the less low level stuff you can even do at all.

That's just what high-level languages do, it's not Microsoft's fault.

Quote:
You see this in the OS, where under XP you either need a 3rd. party tool that basically does registry hacks or hack it yourself to make changes to some basic options that you could easilly tweak under 98 or even NT.

Like what?

Quote:
Now you have .NET, which not only, do to the changes in design, removes some options, it also seperates the coder even further from the option to do some things.

What options does it remove?

Quote:
XAML seperates you even farther.

According to www.xaml.net:
--
The primary use of XAML is in the definition of Client User Interfaces, both describing the graphical layout of the interface, and tying user-Interface generated events to code.
--

In other words it's a specific tool, you shouldn't be using it for things it's not meant to do.

Quote:
This doesn't, as someone used to having the 'option' of using lower level things when needed, particularly impress me about MS compilers, or any of their other software for that matter.

I think you're mixing up the MS compilers and the MS APIs. What kind of low level stuff are you trying to do that you can't in C++?


I think the problem here is just that you're not using the tool for the job... you're trying to make things do what they weren't really meant to do, so then no wonder it doesn't work exactly as you want it. :) Also, just because *you* want it done that way doesn't mean it should be that way; maybe they had their own design requirements when they made their decisions. MS may sometimes have its own agenda, but - for the most part - they aren't at all stupid.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #28 on Tue 18 May 2004 07:43 PM (UTC)
Message
If XP doesn't contain things you can't change within its own system, then why is there still a copy of TweakUI for it and most of the registry hacks at www.regedit.com almost all 2000/XP hacks? Ironically, everyone one of the hacks on the front page there today involve ways to secure the system from anyone changing certain settings or using certain services that MS never provided a direct way to disable (at least without disabling them completely, so they don't even run).

And yes, I understand what you mean by languages being 'designed' to do specific things. But lets look at C++ for a moment. You may have to be completely insane with the efficiency of modern compilers to want to do it, but it 'lets' you use assembly if/when you have to. VB lets you... use API calls, many of which should be functions inside the existing objects. Why for example do you need an API call to get the client rectangle of a window, but the window object is happy to supply you with full window size? Just because that is a property you need to set to use a window, *not* because it is actually useful for anyone trying to create something like a image browser or the like, where you may need to a) display one image for every 100 pixels. You can get the outer rectangle, but you have to 'guess' what the client area actually is. And that client area can change from machine to machine depending on the display settings someone used and thus how many pixels wide they made window borders. Guess what! You also can't get this information directly in VB, so you still can't calculate it without the API call. Why isn't it a property of the window object again???

I have no problem with the idea of using a tool for what it is designed for, but I get a bit annoyed when the only choice to fix a problem is to buy another multi-hundred dollar compiler from the same company, spend a month learning it, another month trying to figure out what I messed up when the program crashed, all because I need one function that the other language didn't bother to provide. The fact that I only have a stone age copy of VC++ from the days of 95 and I am pretty much clueless at coding in C++ anyway doesn't help my mood. I getter really frustrated when I look at MS' site for a clue how to use the API and it turns out you need the header files for VC++ anyway, since they decided to save space by not giving the actually values of any of the flags for those calls.

So, forgive me if I and a lot of other people think that the biggest issue with VB isn't its limitations, so much as the artificially induced limitations that MS gave it by deciding that certain basic information about the objects you use in it shouldn't be available without a) resorting to API calls or b) coding a few hundred lines of C++ into a new dll, just to get back 'one' feature they left out. That's just dumb imho. But then, relying on runtime libraries wasn't terribly bright either. What exactly prevented then from making VB a front end to VC++, so that the pre-compiler just translated the VB into C++ before compiling? I can't see how that would have been any different than using templates in VC++ to 'design' anything.

Anyway. My real problem.. I know that what I need I can do in a week with VB, if only it provided the one feature I need to complete it. I know it would take me months to do it in C++, since I am virtually clueless about that language in the first place and since I still don't really know how to do what I need in that. So, forgive me if I am a tad annoyed at what they left out, both of their own MSDN documentation *and* the language itself.

Oh wait.. I gues the MSDN does give one example of using ambient.usermode.. It refers to a program called Patron, which exists in at least 3-4 incarnations (the author of the Patron programs doesn't seem to have much imagination) and isn't actually available on the web or Microsoft's own site. It is however available from a probably out of print book written by someone affiliated to MS only by the fact that they published the pretty much useless 1-2 pages describing what the program did, but not actually how or with what code. It uses, drum roll please..., a .dll coded in C to manage it. That is the sum total of what you can actually figure out by reading the article. Amazing how their references to 'real' information is even worse than their own documentation. ;) lol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #29 on Tue 18 May 2004 08:08 PM (UTC)

Amended on Tue 18 May 2004 08:10 PM (UTC) by David Haley

Message
Quote:
If XP doesn't contain things you can't change within its own system, then why is there still a copy of TweakUI for it and most of the registry hacks at www.regedit.com almost all 2000/XP hacks?
Hey - I didn't say XP couldn't be tweaked, I was asking what you can do in previous versions that you can't do in XP.

Quote:
Ironically, everyone one of the hacks on the front page there today involve ways to secure the system from anyone changing certain settings or using certain services that MS never provided a direct way to disable (at least without disabling them completely, so they don't even run).
I guess people aren't aware of the group policy editor, or the local security settings? Yes, it's only on XP pro, but, well, XP home is not meant for the power user.

Quote:
And yes, I understand what you mean by languages being 'designed' to do specific things. But lets look at C++ for a moment. You may have to be completely insane with the efficiency of modern compilers to want to do it, but it 'lets' you use assembly if/when you have to.


No - C++ doesn't "let" you use assembly - your *compiler* lets you use assembly.
Besides, weren't you the one complaining about not having low-level access? :P Why are you denigrating the use of assembly?

Quote:
VB lets you... use API calls, many of which should be functions inside the existing objects. Why for example do you need an API call to get the client rectangle of a window, but the window object is happy to supply you with full window size?
Because it's not used enough. VB is not meant for "power apps" that would need to access such things.

Quote:
You also can't get this information directly in VB, so you still can't calculate it without the API call. Why isn't it a property of the window object again???
Probably because the object is an abstraction, and itself may not be aware of the client rectangle. It doesn't need to be.

Quote:
I getter really frustrated when I look at MS' site for a clue how to use the API and it turns out you need the header files for VC++ anyway, since they decided to save space by not giving the actually values of any of the flags for those calls.
Eh!! Of course they did. VB comes with an API explorer or something like that, that has a full database of all the API functions you can call, the constant values, etc. And if not, you can always check the VC++ MSDN documentation online for free.

Quote:
So, forgive me if I and a lot of other people think that the biggest issue with VB isn't its limitations, so much as the artificially induced limitations that MS gave it by deciding that certain basic information about the objects you use in it shouldn't be available without a) resorting to API calls or b) coding a few hundred lines of C++ into a new dll, just to get back 'one' feature they left out.
You can't have your cake and eat it too. The language is meant to be simple, a high level abstraction to make basic GUIs easy to do for non-programmers.

Quote:
That's just dumb imho. But then, relying on runtime libraries wasn't terribly bright either.
Umm, dude, *every single language* has a runtime library of some sort. Why shouldn't VB?
Amendment: Alright, perhaps not pure Assembly... what I meant is that every single higher level language - yes, even C - has a runtime library for the built-in language routines (like malloc, for example.)

Quote:
What exactly prevented then from making VB a front end to VC++, so that the pre-compiler just translated the VB into C++ before compiling?
Because that wasn't the point of the language.

Quote:
I can't see how that would have been any different than using templates in VC++ to 'design' anything.
I don't think you quite understand what C++ templates are. You don't "design" things - especially not GUIs - with templates. Templates are for generic programming.

Quote:
Anyway. My real problem.. I know that what I need I can do in a week with VB, if only it provided the one feature I need to complete it.
I'm still not convinced that you can't. C++ makes the same API calls that VB does. You probably just haven't found the right one.

A minute of Googling revealed the GetClientRect function, which seems to do what you want.

Here is the MSDN documentation page.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Windowing/Windows/WindowReference/WindowFunctions/GetClientRect.asp
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

203,561 views.

This is page 2, subject is 6 pages long:  [Previous page]  1  2 3  4  5  6  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home