No troll. What are the (legitimate) reasons people are still using VB6 ?

Quote:

---

Originally Posted by Shaggy Hiker

The point is that everything is changing. If we knew which technology was going to last for a good long time, that sure would be nice. We don't, though, so everybody takes a gamble no matter which choice we make.

---

Those of us who chose VB6 programming got it right. 20 years and still the best language for Windows desktop.

Add JavaScript to that (for web and mobile) and you've covered most bases.

well, i got/have tools that are java or .net that forces me to install a particular version, not the latest and they are not compatible.
so, sure, u can use 1 framework and keep only that, but what about other programs? or u mean we should only use the tools from 1 dev?
there should only be 1 framework and nothing else, im sure that if VB6 still where to update we would only need the latest as that would include back compatibility.

vb6 is not perfect. but its a good base.
what i would like to have is a language that has a "empty shell" where we add "plugins", that gives us a form, or a button or picturebox (similar to what we already have in vb6)
everything we add will get added in a "data" folder, for easy deployment, no registration.
if the IDE would get updated. we get "new plugins", the empty shell is still the same and will work with "older plugins".

Quote:

---

Originally Posted by baka

.net u need to install the .net framework, how many we got so far?
java is the same. and c++ redistributable. theres more then 10 of that.
VB6 how much we got that need to be installed?
still I can create tools and games that are as advanced as .net and java and c++.
that tells something is wrong. the techs are not that smart it seems.

---

I would be happy with the .NET framework remaining static at the point it is at, just as it is with VB6. Then the framework would come bundled with the OS, just as it has been with VB6, and the issue would go away. However, that wasn't the case early on. There were large improvements in each early version. For example, 2.0 added generics, which anybody in .NET now uses in every program, and that wasn't the most significant addition in 2.0 (I just can't remember the name of the more significant piece). Then 3.5 added LINQ and lambdas (which I have issues with, but they are everywhere), and 4.0 added Tasks (a thinner, easier, means of certain kinds of threading...sort of...except that they aren't always different threads). Since 4.0, the advances have been more specialized and less broadly relevant. That gives me hope that there will be a near final version.

Still, TG is right: This hasn't been an issue in a very long time. I haven't thought about a framework download in over ten years. Most are part of Windows Updates, and they all live happily along side one another, so who cares?

Quote:

---

Originally Posted by baka

well, i got/have tools that are java or .net that forces me to install a particular version, not the latest and they are not compatible.

---

I don't deal with Java, but I've never seen any incompatibility between .NET frameworks. Have any specifics on that? If you are dealing with pre 2.0, I can see it, but then I think you'd have to be dealing with some pretty old Windows version, as well.

Quote:

---

Originally Posted by baka

well, i got/have tools that are java or .net that forces me to install a particular version, not the latest and they are not compatible.
so, sure, u can use 1 framework and keep only that, but what about other programs? or u mean we should only use the tools from 1 dev?
there should only be 1 framework and nothing else, im sure that if VB6 still where to update we would only need the latest as that would include back compatibility.

---

no, the frameworks are designed to coexist. you likely already have several versions of .net and the jdk on your computer. The developer chooses which on they want to target. And if they target features of a newer version, they do have to exist on your computer.

And .net has a stated goal of backward compatibility (https://docs.microsoft.com/en-us/dot...-compatibility). And my understanding is that java is pretty good in this regard too.

not sure, its not that i run apps every day. but i remember this tool that i wanted to run, that didnt run.
so, i looked into it and it read, need v2.0 maybe, or 1.1 dont remember. so i googled that and after a while found an installation.
then another tool needed v3.x and needed to install that as well. got multiple versions in my apps&features.
the same with java, need to install the framework for each version, its not that i can just install the latest and it will work, sure they can work "side-by-side", still theres a lot of files in my hd to run some 1MB tool.
another tool didnt work, because i installed some distributions files, since i installed x.2 instead of x.1, maybe they have resolved all those issues, maybe the tool where bad programmed, not sure, but i got tired of it.

all those frameworks dont win me over, contrary i wonder whats the problem. why can't they create a good and strong IDE, that dont need that huge framework once compiled?
in the end its all machine code to access the motherboard, gpu, cpu, memory, music. even so theres layers of crap that need to be loaded into memory to work.
that is the reason why java/.net didnt win me over and why im still using vb6. why change if its works well? but im not doing big word applications, im doing small tools and games. so maybe thats the reason i dont need .net/java.

Ah, that's different. There are "families" of .NET frameworks. As long as you have the latest in a family, you shouldn't need the earlier ones in the family. Of course, if you have an early one in the family, and some application wants a later one, then you'll have to install that. I don't recall the family tree, and I don't know where 1.0 and 1.1 were in relation to each other, but 2, 3, and 3.5 were all in one family, and I believe 4.X are all one family.

Of course, the OS was also in there, because various Windows came with various frameworks preinstalled, or got them as mandatory (or optional, in some cases) updates. So, if you were always on the leading edge, you'd be always getting the newest before MS pushed it out as an update. It also depended on how the app was delivered. I do internal, web published, applications, in which case I can largely ignore the frameworks. If the user needs the framework, it comes along with the application. I haven't seen a case where the user needed the framework in years, though, possibly because the application is old enough that every user has it as part of the OS, by now, so nobody ever needs to get it. Kind of like VB6. That's the advantage of a static language.

As to why they need them: They don't, which is why .NET Core will be getting away from them. At the time (late 90s), they made a certain amount of sense. I may have it a bit off, but I believe the idea was that there could be a framework for each platform (ok, there were only three that mattered at the time), which would mean that the program would appear platform agnostic. If you called framework method X, such as checking a path, then there could be one implementation for Apple, a different one for Windows, and a third for Linux. Each could "check a path and return a Boolean" in the manner appropriate for that platform. The programmer would call the same method, and not need to know how the file system worked for that OS.

It was a nice theory.

Quote:

---

Originally Posted by Shaggy Hiker

It was a nice theory.

---

Class-Frameworks are not a theory - but common practice.

"A bunch of Wrapper-Classes" around (potentially differing) APIs are, what most devs associate the term "framework" with.

Frameworks are abstraction-layers, which modern software-development needs badly:
- for Web-Development - js-(Class-)Frameworks abstract from different implementations in different Browser-Engines or -Platforms
- for Desktop- and Server-Development - Class-Frameworks for "compiling languages" abstract from the underlying OS-platform (-APIs)

From my point of view - a good language has only a small(er) runtime (to abstract from some base-functionality of the current OS) -
e.g. the C-runtime (msvcrt.dll) does it in that "down-sized" manner - and the VB6-runtime (msvbvm60.dll) does it in a similar way (with a bit more "base-functionality").

Additional functionality should be "addable" from an "eco-system, which experienced and specialized devs provide and keep-alive".
- the C-guys find their stuff in dozens of well-implemented (usually platform-independent) "flat-C-API-libs" (with *.h files as interfaces)
- the VB6-guys find their stuff in dozens of well-implemented COM-libs (which have the interface included in the binary as a typelib).

That's KISS - and with .NET-Core MS tries to "paddle back" to that approach
(a relatively small CoreLib + additional stuff via the nodejs packetmanager NPM)

A side-note to the VB6ers here:
Putting a ton of API-declares into each of your Applications is *wrong* (these days), because it's platform-specific.
Such stuff needs to be encapsulated away behind Class-Abstraction-Layers (implemented in OCXes - or better: in COM-Dlls)...
Your App-Level-implementations (where you put most of your own coding-efforts into) should follow the goal,
to not use any API-declares - if you not refactor your Apps to use such abstraction-frameworks in the next years -
then your Apps will "forever remain on the Win-Desktop-Island" (which the waves are slowly eating away).

Olaf

You know Olaf that for any decent app that rule is impossible to follow.

no, its like all those new ages pre-2012 that told everyone 2012 its the end, and what happened? nothing.

VB6 works right now, i enjoy working with API's and typelibs, i really dont care about apple/linux, everything i do i do in my spare time. i dont care about money.

This Fearmongering is starting to get old. we don't need to do anything. *wrong* is your opinion, its not truth.

what I believe is that the way they created VB6 is the right path, the language is fun to use, the COM-libs are genius.
it should be fun to do programs and I believe its possible to create a VB6 that works very similar to VB6 but offers cross-platform as well, without a huge framework, but COM-libs.
sure. there will be a lot of work to make a apple/linux counterpart, so its not an easy path. but since i actually dont care about apple/linux, i just need a VB6 that works on a PC/windows.

but since Olaf loves frameworks, i think i need to look elsewhere for that "promise" VB-IDE, as I dont want to be imprisoned in his framework.

Quote:

---

Originally Posted by Schmidt

Class-Frameworks are not a theory - but common practice.


Olaf

---

That's a figure of speech. It's not a literal theory in the scientific sense. I used the phrase because there isn't a totally clean alternative translation. Effectively, you could say that theory, in that case, means "a vision for how something that is being designed, is supposed to work once it has been completed."

Quote:

---

Originally Posted by baka

what I believe is that the way they created VB6 is the right path, the language is fun to use,

---

I think that's the key value of VB6, and not something that has been replicated in ANY other language. It sure isn't found in JS. I feel VB.NET is easy to use, but I wasn't coming to it from nothing. On the other hand, I didn't come to VB6 from nothing, either...I came to it from VBA. I would expect that to be a pretty common on ramp.

Anyways, what I wanted to say is that, despite agreeing with that statement, I work for somebody who doesn't quite agree with it. He has created his own language (it's available on Google, but I couldn't say where, or what it's called) because he wanted an instructional language that was easier to use. Yeah, that's right, he felt that VB6 was too complicated to be a good beginner language.

Having looked at what he wrote, I kind of see his point. He was making a language for getting young kids into programming, which is something of a passion of his. He could do some things in that language that were astonishingly simple. Folders? Databases? They're all the same. You access them the same way, and it's SUPER simple (though not graphical). With the same few characters (and only three or four), you could see the files in a folder or the rows in a table in a database...or maybe the fields. You didn't even have to know whether you were looking at a folder or a database. It was pretty amazing, though I didn't get into it enough to see the limitations, and there obviously have to be some. I might also say that he's a programmer's programmer in that he loves "figuring it out" a lot more than completing things, so most projects end at 99% finished.

thats also what microsoft have been trying to do with windows, to make it as easy possible, intuitive and automatic.
but it also made the os a bit tricky, as everything is hidden and its hard to know what to do if you want to change a parameter, since windows have some automatic functions for that.

the key is to make a language in the middle. both easy and complicated.
if its too easy, you get the feeling that you are not in control, something is doing the job for you but you dont how it is doing it.
if its too hard, you get stuck and could push you into a "helpless" state where you go around and ask help but you never get the feeling of it and you grow very slowly as a programmer.

VB6 is a middle language. its easy to start, but hard to be an expert, you can still learn new things and we can still build on it, add new features.

for me a language is the syntax. if it makes sense. but also availability, a community is important, help-sites (all those API descriptions sites)
sure, theres a lot of API that are not converted, VB6 is abandoned and you can feel it, theres not that enthusiasm anymore. VB6 sites usually dont grow and new tricks sites are rare.
but that doesn't mean VB6 couldn't use it or couldn't grow more. tons of API that are not used because nobody mention it, only the experts know how to do, where to look and convert. the same with typelibs.

i wish for more typelibs, more experts and more help-sites. VB6 is not done.

Quote:

---

Originally Posted by baka

the key is to make a language in the middle. both easy and complicated.
if its too easy, you get the feeling that you are not in control, something is doing the job for you but you dont how it is doing it.
if its too hard, you get stuck and could push you into a "helpless" state where you go around and ask help but you never get the feeling of it and you grow very slowly as a programmer.

---

My opinion: not in the middle, but in both extremes.
I explain: when using defaults, the things should be very easy to set up and get running. But still, there must be the possibility of "customizing" in deep almost everything.

VB6 is good in that regard, but it could be much better (for both ends: 1) to be easier to do so things using defaults and 2) to be more "customizable" without having to resort to subclassing and using so much APIs)

exactly Eduardo, VB6 could be much more and make things even easier, we have discussed this many times in other threads, what we would like to have.
all those improvement that we usually want could be added without the need of any additional libraries, usually its just a limitation of the IDE and how the compiler can understand some stuff.
like const arrays, or if array = nothing, if a = [1 or 6] then, mouse wheel, dim arrays + value, monitor sync (that we can use as a timer) and more small things.

Quote:

---

the key is to make a language in the middle. both easy and complicated

---

Quote:

---

My opinion: not in the middle, but in both extremes

---

To me that's a distinction without substance but I do think the underlying principle is important and does feed into the 6 vs .Net debate.

What you're both really saying (I think) is that a language should make easy stuff really easy but you want a path that leads you to full control. Ideally that path should be as easy as possible but not at the expense of sacrificing control. In other words, give me layers I can work at and progress through. I can get behind that.

The reason I say it feeds into the 6 vs .Net debate is that I feel both do this fairly well but with differing levels of emphasis. 6 made easy stuff really easy. I would argue that .Net made it pretty easy too, but I think 6 probably did a better job of it. As you progress through "middling" levels of complexity I feel .Net probably does a slightly better job of abstracting away some messy stuff but nothing that 6 can't handle. Once you get to the really sharp end, neither is great and, realistically, you start stepping outside the strict confines of the language and start bringing in API calls, C and so on. Both actually do a pretty good job of allowing you to step out of those strict confines though.

And that brings me to this:-

Quote:

---

Putting a ton of API-declares into each of your Applications is *wrong* (these days), because it's platform-specific.
Such stuff needs to be encapsulated away behind Class-Abstraction-Layers (implemented in OCXes - or better: in COM-Dlls)...
Your App-Level-implementations (where you put most of your own coding-efforts into) should follow the goal,
to not use any API-declare

---

I agree with that 100% but not just for the same reasons as Olaf. Abstracting away platform specific stuff to give yourself cross-compatibility is a good thing but just as important to my mind is the fact that it simplifies your application code. Get all of that stuff out of your application and shove it down in some libraries that conform to a published interface. I'm less concerned about the protocol you choose (I'm a fan of REST services due to their open nature - but everyone has a fetish) but you absolutely should be pursuing that logical goal. It is that approach that will allow you to handle progressive complexity as easily as possible.

Quote:

---

You know Olaf that for any decent app that rule is impossible to follow.

---

For refactoring an existing app, probably. But for a new implementation I disagree.

Quote:

---

Originally Posted by FunkyDexter

Once you get to the really sharp end, neither is great and, realistically, you start stepping outside the strict confines of the language and start bringing in API calls, C and so on. Both actually do a pretty good job of allowing you to step out of those strict confines though.

---

Bolt integrated x86 ASM to VB6 and this will make a difference! Unless .Net languages get integrated IL assembler :-))

(Integrated means that in mov localVar, eax the local variable is automagically resolved to dword [ebp+18] for instance.)

cheers,
</wqw>

In .Net you'd put your ASM into a separate dll and call it via Interop. But in both cases I think I'd argue that this is stepping outside the bounds of "VB". That's kinda my point really. Both allow you to go way beyond the limitations of the original language if you're willing to jump through a hoop or two. I view that as a positive for both.

You can encapsulate and perform abstraction at the source level, by creating classes and custom controls that you reuse.

This can fall apart when it leads to long compilation times or running into compiler limits. But at that point you can always take groups of related classes and separately compile them as DLLs/OCXs.

You could also make use of static libraries though that isn't something that the VB6 tools were designed to accommodate, making it less viable for VB6.

However you do not need to shove anything and everything you can think of into one or a few grab-bag kitchen-sink megalibraries. That just complicates any effort to add features, optimize, fix bugs - or port code where that makes any sense. That reminds me of the gag about mountain climbers roped together... "When one falls they all fall."

Microsoft open sourced WinForms last month and someone has ported it to wasm giving you winforms in the browser: https://github.com/roozbehid/WasmWinforms

I wonder if there is anything we can do to get vb6 opened up or at least a definitive answer. The vb6 community could be doing amazing things with the right tools.

Quote:

---

Originally Posted by dilettante

You can encapsulate and perform abstraction at the source level, by creating classes and custom controls that you reuse.

---

Sure, wrapping App-specific stuff up behind Project-Private-Classes (or Project-Private-UserControls) is good practice.

But that's only where you start...
Some of those Helper-Classes become only then a true abstraction, when you choose "good candidates" among them,
which you then refactor in a way, so that they become commonly usable in a generic fashion.

And at that point, those "generically refactored, formerly App-specific Classes" should be moved into their own Projects,
to be able to compile them into their own Binary.
The goal here is obviously:
- to free your Apps CodeBase from any non-specific Code (instead you include a Binary-Reference to your now generic Dll-Class(es)).

Quote:

---

Originally Posted by dilettante

However you do not need to shove anything and everything you can think of into one or a few grab-bag kitchen-sink megalibraries.

---

Not sure, where you define "the limit", when such abstracting Class-Libraries become "mega"...
Is it 0.5MB? ...or do you draw the line at 1MB or 2MB? ... Zipped? Unzipped?

In my book, it is always a subjective decision...
(which each developer has to make on his own, which Classes are aggregated in which Dlls,
depending on the differing objectives which each dev might weigh differently).

I'd say, a Deployment-package is "small enough" when:
- it downloads in less than a second (or two)
- and if it can be installed (registered) in a second or two
(both is true for e.g. the RC5-package)

Quote:

---

Originally Posted by dilettante

That just complicates any effort to add features, optimize, fix bugs...

---

You seem to be unaware of the fact, that the Classes in a larger (aggregating) ActiveX-Dll-Project can be organized in Sub-Directories.
You can then define dozens of separate *.vbp and/or *.vbg for "SubAreas" within the whole Code-Tree for convenient developing/testing-purposes.
Only one of those *.vbp's needs to include the "complete functionality for aggregated compilation" (that's how I develop and have organized the RC5-lib).

Quote:

---

Originally Posted by dilettante

That reminds me of the gag about mountain climbers roped together... "When one falls they all fall."

---

You have it completely backwards (since we talk about COM-dlls).
If you develop a true framework (Class-Functionalities which build upon each other), you are really bad advised to split such functionality up into:
- a dozen of "Sub-Dll-Projects, which then end up cross-referencing each other"!

Make a mistake (when shipping the next release) and everything will fall apart (when Refs don't match across Projects, and their respective Dll-Binaries anymore).
That's IMO exactly, why a "Merger-Project" makes a whole lot of sense.

Olaf

Context: about not using APIs...

I had said:

Quote:

---

...for any decent app that rule is impossible to follow

---

(not to use APIs)

Quote:

---

Originally Posted by FunkyDexter

For refactoring an existing app, probably. But for a new implementation I disagree.

---

Half of the questions in this forum (OK, may be a little less) are about things that the answers need to use APIs to provide a solution.
That's true for VB6.
If you are exigent with what you want to do and how it should work, many times you cannot do it another way, you need APIs.

You can negotiate and say: "OK, I'll abandon this idea of mine about this easy-to-use GUI feature that I wanted to put, so I don't need to use API" and things like that, but that's not my idea of quality and professional software.

For example (an extreme example), you could use just labels, textboxes and commanbuttons for the GUI, and nothing else. Yeah, everybody could develop programs with just these three controls. Why not? Of course it could be possible.
But would you like that?

I don't get the problem with a bigger "mega" library either. In fact, a few years back one commercial product that I've used for years (Chilkat) moved to a single "mega" library from a whole bunch of smaller more single purpose libraries and it was a relief. Prior to the merge you had to keep careful track of which libraries referenced each other, and there was a slightly complex web of dependencies. Once it was decided to merge everything into a single DLL, deployment became much easier. The Chilkat library is about 9MB compared to the 5-6 MB of vbRichClient5, but is anybody really complaining about distributing 5, 10, 15 or even 20 MB of libraries in 2019?

if you give me a VB6+ (where i need to include a MEGA.DLL when releasing my tools/games) where I dont need to register MEGA.DLL, no i just put it in the same folder or data\ folder of the application, i dont mind if MEGA.DLL is 1, 10, 30 or even 100MB in size.
if that library replaces all the API and VB6 dependencies (in windows system folder) for me its a good thing.
I dont mind if I need to learn a bit of how to use the MEGA.DLL, maybe similar to a typelib, where I can click F2 and see all the functions/utd/collections/const etc.
but I need to know how to use MEGA.DLL, all the "functions" need to be easy to use and with help how to use it, and how to use a bunch of functions together.

Quote:

---

Originally Posted by Eduardo-

For example (an extreme example), you could use just labels, textboxes and commanbuttons for the GUI, and nothing else. Yeah, everybody could develop programs with just these three controls. Why not? Of course it could be possible.
But would you like that?

---

It's not a bad way to think about it. Windows CE left out a whole lot of controls. If you have a label, a textbox, and a command button, you can build many of the other controls. A listbox is a label with a series of other labels in it. A slider bar is a label with a button in it (or another label), a grid is a label with a series of textboxes in it...and possibly a scrollbar, but that's already been described.

The three you mentioned may be about all there is. The rest are conceptually built from those for the convenience of the programmer, just as all higher level languages are conceptually built from ASM for the convenience of the programmer. The analogy is far from perfect, of course, since a listbox has a single window handle, so it isn't really composed of a bunch of labels, but it could be, and in Windows CE, it had to be.

Quote:

---

Originally Posted by Eduardo-

I had said: ...for any decent app that rule is impossible to follow ...(not to use APIs)

---

You probably misunderstood... (not sure though)

What I meant was:
"The *.vbp Project which you later compile into your "MyApp.exe" should not contain any API-Declares (to System-specific Dlls).

To follow this rule is absolutely possible - and especially important when you write *larger* Apps.

Olaf

Quote:

---

Originally Posted by baka

if you give me a VB6+ (where i need to include a MEGA.DLL when releasing my tools/games) where I dont need to register MEGA.DLL, no i just put it in the same folder or data\ folder of the application, i dont mind if MEGA.DLL is 1, 10, 30 or even 100MB in size.

---

Thankfully, you already don't need to register DLLs if you use an SxS manifest or Olaf's DirectCOM.dll for reg-free instantiation.

Quote:

---

Originally Posted by Schmidt

You probably misunderstood... (not sure though)

---

I thought I had understood, but reading this message I'm not sure...

Quote:

---

Originally Posted by Schmidt

What I meant was:
"The *.vbp Project which you later compile into your "MyApp.exe" should not contain any API-Declares...

---

The declares are in code modules (*.bas, *.frm, *.cls, *.ctl) but not *.vbp files.
So no, I'm not understanding.

Quote:

---

Originally Posted by Schmidt

API-Declares (to System-specific Dlls).

---

What do you mean "System-specific"?
1) Do you mean just one Windows version, for example Windows 8?
2) Do you mean Windows as a whole?

For case of 2), in VB6 we cannot make API declares for example for Linux or Android.

Quote:

---

Originally Posted by jpbro

Thankfully, you already don't need to register DLLs if you use an SxS manifest or Olaf's DirectCOM.dll for reg-free instantiation.

---

Yes, that issue of installing components into the Windows system folder should be something of the past.
Unfortunately, there is not an easy to use utility to make installation packages (yet).

we dont need labels, textbox or commandbutton at all, we just need a form.
in the games im using i just use the form and everything added to it, buttons, label, textboxes, frames, sliders, drag/drop mechanism, are all dynamically added.

what im trying to say is that we just need a form, the "common" component are old and outdated. everything need to be replaced.
that is now dilettante will say to me: why are u using VB6, why not freebasic or something similar.

i like using VB6, even if I dont like the common component or most of the component. i never add any component actually, but i add references, typelibs and such.

what i like is the "game-loop" method.
now with direct2d, i only use that, and i get a nice refresh rate with the monitor, smooth and that also gives me the timer.
with the API GetDeviceCaps, i can accurately get the exact time each refresh circle, making the timer almost perfect, at least for my needs.

from here, if i want, i could start creating component that works "together" with the game-loop that i can reuse.
buttons, textboxes, labels, that all can use opacity, and of course DPI aware without any manifest or API calls.

any kind of component can be made from there. they just need to follow the "syntax" of the loop.

the game im doing now is both a game and a editor, with a simple key press, it brings me up a panel, where i can add/remove stuff, create rectangles dynamically, drag and drop, type text that follow the rect with different colors and symbols and links, tooltip, etc.
so anything is possible, the question is can it be used again? will other people have use of it? will they use it at all?

since i dont care about making word programs or utilities tools, i have little use spending time creating components, but its possible, without the need of any VB6 components at all, except the form.

Quote:

---

Originally Posted by jpbro

Thankfully, you already don't need to register DLLs if you use an SxS manifest or Olaf's DirectCOM.dll for reg-free instantiation.

---

i tried and it did get me errors, i could add the references, gave me errors, Olaf couldn't help me either.
the register free is not working like i want. when i try in the IDE i can't make it work, can't even try it.
not sure how u did. i wrote that x months ago. i wanted to give it a try, but how can i do that if i can't even start it? i register his libraries but that didnt help.
i dont like SxS manifest.
(I get Error in loading DLL, after I click vbRichClient5 in the references)

Quote:

---

Originally Posted by Eduardo-

I thought I had understood, but reading this message I'm not sure...

The declares are in code modules (*.bas, *.frm, *.cls, *.ctl) but not *.vbp files.
So no, I'm not understanding.

---

IMO deliberately so... ;)

A *.vbp defines (primarily) the code-files you've listed above, so when I mentioned *.vbp -
I obviously meant (now trying to be very precise, especially for you):
"The code-module-files which are contained and aggregated in your StdExe *.vbp definition-file...
- which in turn you will later pass to the VB6-compiler ...
- which in turn will later parse your *.vbp and compiles all the code-module files into your "MyApp.exe" ...
- should not contain any API-Declares...

Quote:

---

Originally Posted by Eduardo-

What do you mean "System-specific"?
1) Do you mean just one Windows version, for example Windows 8?
2) Do you mean Windows as a whole?

For case of 2), in VB6 we cannot make API declares for example for Linux or Android.

---

I meant #2 obviously.

And yes, *currently* you cannot make API-declares to (usually *.so suffixed) Linux/Unix libs -
but there are Basic-compilers (32- and 64Bit) which support the VBA/VB6 Declare-statement-syntax in a platform-independent manner:

E.g. this SQLite-Declare in FreeBasic will work (unchanged) on Windows (sqlite3.dll) and Linux (sqlite3.so):

Code:

---

'for 32Bit compilation
Declare Function sqlite3_open CDecl Lib "sqlite3" (ByVal pFilenameUtf8 As Long, ppDb As Long) As Long

'alternatively for both: ( generic 32- and 64Bit- compatible compilation, quite similar to the syntax in 64Bit-enabled VBA-projects )
Declare Function sqlite3_open CDecl Lib "sqlite3" (ByVal pFilenameUtf8 As Any Ptr, ByVal ppDb As Any Ptr Ptr)  As Long

---

But preparing for (later) platform-independence is only one thing you'll manage when following this rule.
FunkyDexter already mentioned other benefits of "working through Class-abstractions" (since it allows you,
to switch to another Class-Abstraction (which implements things differently) very easily!
(without changing a single line of User-Code across your whole StdExe-*.vbp
(to be precise again - without changing a single line of UserCode in all your UserCode-file, the *.vbp contains).

HTH

Olaf

Quote:

---

Originally Posted by baka

i dont like SxS manifest.

---

Neither do I ... hence the little DirectCOM.dll (which is included as the 3rd Dll in the RC5-BaseLibs-Zip).

Quote:

---

Originally Posted by baka

(I get Error in loading DLL, after I click vbRichClient5 in the references)

---

If you are seriously interested in making an attempt, then follow these steps (on the machine, where you cannot install - or reference it):
- deregister the older version using regsvr32 from syswow64 with admin-elevation (ask "the forum", if you have no clue what that means)
- download the latest version (the BaseDlls-Zip)
- unzip all files the Zip contains into e.g. C:\RC5\ ... (or another Folder of your choice)
- register (only) vbRichClient5.dll using regsvr32 from syswow64 with admin-elevation (or alternatively use the contained helper-scripts for that)

If the above does not work out of the box for you - then you're doing something wrong
(but I'd be glad to help you in more detail, in a different thread than this one here - or even via PM).

Olaf

Quote:

---

Originally Posted by Schmidt

IMO deliberately so... ;)

A *.vbp defines (primarily) the code-files you've listed above, so when I mentioned *.vbp -
I obviously meant (now trying to be very precise, especially for you):
"The code-module-files which are contained and aggregated in your StdExe *.vbp definition-file...
- which in turn you will later pass to the VB6-compiler ...
- which in turn will later parse your *.vbp and compiles all the code-module files into your "MyApp.exe" ...
- should not contain any API-Declares...



I meant #2 obviously.

And yes, *currently* you cannot make API-declares to (usually *.so suffixed) Linux/Unix libs -
but there are Basic-compilers (32- and 64Bit) which support the VBA/VB6 Declare-statement-syntax in a platform-independent manner:

E.g. this SQLite-Declare in FreeBasic will work (unchanged) on Windows (sqlite3.dll) and Linux (sqlite3.so):

Code:

---

'for 32Bit compilation
Declare Function sqlite3_open CDecl Lib "sqlite3" (ByVal pFilenameUtf8 As Long, ppDb As Long) As Long

'alternatively for both: ( generic 32- and 64Bit- compatible compilation, quite similar to the syntax in 64Bit-enabled VBA-projects )
Declare Function sqlite3_open CDecl Lib "sqlite3" (ByVal pFilenameUtf8 As Any Ptr, ByVal ppDb As Any Ptr Ptr)  As Long

---

But preparing for (later) platform-independence is only one thing you'll manage when following this rule.
FunkyDexter already mentioned other benefits of "working through Class-abstractions" (since it allows you,
to switch to another Class-Abstraction (which implements things differently) very easily!
(without changing a single line of User-Code across your whole StdExe-*.vbp
(to be precise again - without changing a single line of UserCode in all your UserCode-file, the *.vbp contains).

HTH

Olaf

---

Then the options are:

1) make the program very "flat" and "boring" and outdated.
2) move everything that require API calls to a component, so when sometime in the future appears a VB6 replacement that can compile multi-platform, one can do the component versions for the other platforms.

Still, I don't see much of the point since:
Unless something unexpected happens and many people start using Ubuntu or another Linux version, there is no point on making such an effort for Linux.
Mac is another case, because people that buy Macs may be more prone to pay for software, so even if there are less users, there could be some value in compiling to Mac (but I'm not sure anyway).

The real multi-platform today IMO is: Android, iPhone and WebApps.
And specially WebApps.

But for WebApps, any program would have to be redesigned anyway, unless they have been designed from the start separating layers.

So, I don't see much of gain for a program designed today with desktop in mind to potentially compile to Linux and Mac. We will be stuck in desktop programs for PC anyway.

And that presuming that there will be a VB6 successor.

Edit: my point is the sacrificing UI today for the sake of potentially being able to compile to Linux and Mac in the future doesn't seem to be a good decision (at least for me).
Since what I really want is to be able to compile to a WebApp platform. And not using API won't help much in that regard.

Quote:

---

Originally Posted by Eduardo-

Then the options are:

1) make the program very "flat" and "boring" and outdated.
2) move everything that require API calls to a component, so when sometime in the future appears a VB6 replacement that can compile multi-platform, one can do the component versions for the other platforms.

---

#2 above is, what "all my talk is about"...
...as well as one of the reasons for the existence of the RC5, which allows "nearly API-free development" - and internally already makes use of:
- a whole lot of platform-independent libs for critical parts of the GUI and "local DB-access" to reduce future porting-efforts in the RC5 itself
- (meaning a ton of Declares against libCairo and sqlite3 (*.dll or later *.so), ...
- since these OpenSource-Lib-Declares will later work on Linux as well... I don't have that much to change in the Classes which wrap these flat-API-libs, when I port the RC5 to Linux

So, if baka (further above) talks about "imprisonment by using the RC5-libs when using it as an abstraction-layer today", he has it completely backwards -
because (as I see it) I'm currently the only VB6-dev, who has a well-thought-out roadmap (and who has already invested a ton of work too) -
"to get you all out from behind the bars of the Windows-prison", so to say...

If you take Krools CommonControl-Replacement-Project for example (which is a "Class-abstraction-layer" of course) -
but still there's a ton of System-specific Declares in it, which would require enormous efforts, to port it to Linux... (it basically has to be rewritten from scratch)

Now - if you look at the work invested into the vbWidgets-Project on GitHub (which offers basically the same set of Controls) -
there's exactly 4 System-Declares in it (Ok, 9 more in cIME, which is a sidewards-addition for east-asian languages, and not really critical "to get things going and compiling").
But this Project would be portable nearly without any code-change on my part, because I've eat my own dogfood when implementing stuff in vbWidgets by "following the rule" ...
(of working through an abstraction - provided by the RC5-lib in this case).

It's probably the lack of understanding of "such architectural things", which causes all the "hubub" around the RC5 here in this Forum.
We all need to come out of our "Windows-Shells" at some point in time - a potential VB6-successor only has a future on "something else than Windows",
I'm absolutely convinced about that.

Olaf

Quote:

---

Originally Posted by Schmidt

a potential VB6-successor only has a future on "something else than Windows",
I'm absolutely convinced about that.

Olaf

---

If you've read my last post, I am of the idea that the way to go for future apps is WebApps.
Still, even in the "ideal case" where the VB6 successor can compile to a WebApp environment, there will be problems/limitations with that approach since web browsers were not designed for running Apps in mind.
Perhaps in the future web browsers (and HTML5... or HTML6) will evolve to something more WebApp friendly.

Also, sometimes, there is the need to run native Apps. In that case IMO the need is mainly for Android and iPhone.
I only had one case of an user that wanted to run a program of mine on Linux.

So, to work another decade to make some -limited anyway- kind of VB like environment that can compile to Linux... I don't know if it is a good investment.
If the idea is to do it for fun, then yes it will be a well invested time of course.

Or.. may be I'm completely wrong and Linux is the OS of the future, that everybody will be using in some years.
It might be, it is not too crazy to believe that, but it is not what it seems today.
It only would take that some foundation like Mozilla create a Linux version that could be a good job in most of the tasks that Windows does, and to be easy to install and easy to use.
The Linux craw today make the things hard to use because they want to feel that they are exclusive. But it would only take some group with another purpose and another ideas.
But enterprises want to make money. How a company would make money doing that? That's perhaps why it didn't happen to this day. Google could do it if they wanted I think.

Who knows. Still the WebApp would run on Linux.

has anyone (@baka?) attempted a D3D10/11/Direct2D App on Wine(linux) in VB6 yet?
I actually am a huge fan of D2D in VB6 now, and the latest MS Office also uses DXGI/Direct2D as well.

Quote:

---

Originally Posted by Eduardo-

Or.. may be I'm completely wrong and Linux is the language of the future, that everybody will be using in some years.
It might be, it is not too crazy to believe that, but it is not what it seems today.

---

I suppose "Linux is the language of the future" was a typo and you meant "Linux is the OS of the future".

I believe it is. It's the OS for servers for a long time, and the desktop is almost there. There's some work to replace android with linux too. OSX is already linux (or a kind of).
The fact is that windows future doesn't seem promising, does it?

I have 3 PCs and a laptop at home. My own PC is the only one with Windows because all the tools I need requires it and it would take me months to move everything, but I'm trying.
VB6 is already installed but not deeply tested, and my lovely Visual Objects (my primary programming language) is already running there and seems to work fine.

My other PC is a server with Debian 9 for a long time, with lots of things for work and home use. It serves some movies for my kids, that they use from a small box connected to the TV. This box came with android, but it's now with CoreElec, a small linux distribution to run Kodi.

My wife's PC is currently running Lubuntu and she's happy with it. Apart from the browser she only needs Adobe Photoshop and it is working flawlessly in there (my wife even said it appears faster on linux).

My 11 yo daughter has a laptop with Lubuntu that amazes her math teacher at school. Unfortunately, they use MS Office at the school and my daughter uses LibreOffice, and it seems there are a few formatting issues, tho nothing serious.

Anyway, with windows going from bad to even worse we don't have too many options, so the faster you adapt the safe you are.

So, yes, I believe linux is the future. It's already the most used OS in the world.

Quote:

---

Originally Posted by DEXWERX

has anyone (@baka?) attempted a D3D10/11/Direct2D App on Wine(linux) in VB6 yet?
I actually am a huge fan of D2D in VB6 now, and the latest MS Office also uses DXGI/Direct2D as well.

---

Why should anyone invest time to learn an MS-specific API (now), when it's nowhere else supported (other than on Windows)?

It's pointless IMO - when there's so many platform-independent lib-alternatives which offer GPU-support as well,
(as e.g. SDL or OpenGL for example - the latter even with a nice VB6-compatible *.tlb).

As for your question:
Whilst the DirectX-support on Wine is (traditionally) quite good (due to the Linux-gamers) one cannot say the same for D2D on Wine:
https://github.com/SynEdit/SynEdit/issues/91

And one definitely cannot use D2D on Android or iOS (or ARM generally ... whilst OpenGL (ES) and SDL work just fine on ARM-based platforms).

Olaf

never tried wine, but its quite interesting
https://www.ghacks.net/2018/01/18/wi...nd-11-support/

so, thats a possible graphic engine alternative to replace gdi32/+ completely.
im also a huge fan of D2D, and i think its strange that we use gdi at all.

right now, if u r serious with 2d graphics, it should be cairo or d2d.

i wonder, can u run vb6 programs in wine?
what api, components, audio dll works in wine?

i would love to have a typelib that gives me all the functions that are supported in wine.
and only references to libraries that also works in wine.
this could be the first step that i need to do to be more aware of other os.