Hi Olaf

I got hooked to ur dhRichClient tools 3 months back was just experimenting
with ur demos & reading discussions here .I don't have a specific issue as
for now
but will request a couple of things

#Can't we move all the discussion here to consolidated forum so lack of
documentation can be supplemented by questions & answers

# Are there any windows version issues with the lib(s) i guess with new
version its working on 98 as well

#One word ----Documentation----- ' simple one liners for method descriptions

(dbadapt.dll for databinding took me a new VPC & 48 hrs to find out :-(

thanks anyways for wonderful library, would really want this to turn into a
bigger phenomena & looking forward to vbwidgets can u give some future date
for it.

Nitin <Ni***@discussions.microsoft.com>'s wild thoughts were
released on Tue, 7 Jul 2009 07:46:01 -0700 bearing the
following fruit:

Show quoteHide quoteI don't know where you actually meant to post this, but I'm
certain it isn't here.

well i m posting here first time though microsoft.public.vb.general.discussion
i have read a few posts regarding  dhrichclient3 toolset from
Olaf Schmidt  http://www.thecommon.net

enlighten me if I m doing some thing wrong here

Show quoteHide quote

Your post just seems to be directed to an individual. The newsgroups are
intended for peer-to-peer open discussion. You're making some specific
requests to Olaf and the newsgroups aren't really the place for that.
There's not even a certainty that Olaf will see your post.

And since you asked to be enlightened...you should follow the same posting
format that has been established.  Jan quoted your post and wrote a reply
under that.  That's called bottom-posting.  You then replied to Jan but
wrote above what Jan had written.  That's called top-posting. Most people
don't care which is used.  But to make things easier on everybody, you
should follow whichever was established. When top-post quoting and
bottom-post quoting all get mixed up in replies, it gets REAL difficult to
follow the flow of the conversation without going back to the thread's
previous posts ...and the whole purpose of quoting is so people don't have
to do that to understand what's being discussed.

I'm top-posting to this because that's what you did (and therefore you
established a different format). But now, if somebody replies to THIS
message and bottom-posts...well....just try to follow the flow of the
conversation.  <g> The carets, arrows, whatever you want to call them, which
indicate a quote only help so much.

Mike


Show quoteHide quote

Show quote Hide quote Guess this is write way to reply Mike
Now ur on top LOL
Thanks for that

my post might have been directed to Olaf but what I meant to discuss was
dhrichclient3 libs & peers using it
any windows version problems anybody facing so I can make a informed
decision for committing it to future projects

so I meant to move this individual topic discussion to a specific forum

microsoft.public.vb.general.discussion
  What you're doing wrong is asking for private, 3rd-party
tech.support in a public VB forum.

Olaf's site has a contact email address:

i***@datenhaus.de

   At the same time, the package is given away for free.
You can ask for more docs but they may never materialize.
Maybe you should write to Olaf and offer to help write
the docs. That's apparently not his forte. :)

Hi Nitin,

Maybe you should contact the author directly and suggest that he actually
sets up a forum.  If the project is really open source, there's plenty of
great free code sharing sites that allow for discussion. There is absolutely
no need for it to be in here.


Show quoteHide quote

Moving "*all* the discussion here" is probably not the best idea.
But in case you have a specific problem (reagarding your
own VB-Code, which in case of dhRichClient3.dll deals
with "just another library available for VB-Classic") - I don't
see, why you shouldn't ask such *concrete*, coding-related
questions here in this forum.
ADO/JET related questions are welcome here (or in the
vb.database-group) - so why not asking such stuff, which
does make use of appropriate alternative libs, which cover
basically the same topic.

There is a good chance in the meantime, that other users of the
lib are able to answer such concrete questions too (not only me),
but I'm hanging around here of course - and some users of the lib
are aware of that and probably "just hold back" with their replies.

The library works without problems on "W2K-and-above" Win-
versions with the "full functionality" - and my latest "Win98-
compatible"-enhancements (done some weeks ago, on request
from a chinese user) made most parts of the lib (especially
the DB-classes - regarding the unicode-topic) available again
also on that older platform.

Currently there are no open bugs in the library - thanks to
everybody (at this occassion), who reported such bugs
together with small VB-code-snippets per E-Mail.

The lib is mature now - and also the COM-interfaces are stable -
so no larger changes are expected in the next months/years
regarding BinComp-breakage.


That is already "documented" within the Main-SQLite-Demoproject
(inside the larger "OnTop-Comments" inside fMain.frm) - but as
already stated often enough over the last weeks - the Documentation
needs a central place and a clean structure, just extensive Demo-
Code (with documenting comments) is not enough for most
of the lib-users.

That's my goal too in the next months/years - and I'm very
serious about that ... as already stated above - thanks to the
broader usage, which was increasing over the last years, the lib
is in a real mature state now...
I use it within "datenhaus-related" projects for more than just
one year of course - but only covering/touching a smaller
spectrum of all the possible use-cases - so the currently
existing user-base (community) already was of great help
with regards to fixing also the bugs within these "not thouched
that often, darker corners"... thanks again.

And to Jan, Mike, mayayana ...whoever replied to (or reads) this:
There are no commercial intentions behind that library - there's
no "hidden hook" or something like that...
As stated on thecommon.net, what I want to achieve is to
offer something like a vbRuntimeEx.dll - usable without any
restrictions by the VB-Classic-community, covering (difficult)
infrastructure-topics and -primitives with C-like performance,
behind nice VB-class-wrappers - with as low (MS-)COM-
dependencies as possible, to be better prepared for the new
upcoming Win-versions - with the final goal, to "move on"
with VB-Classic-Code (my own, existing Codebase of course,
but also *your* existing codebases) ending up with a new compiler,
which does make use of all the existing (class-based) functionality
of the toolset as its new (enhanced) VB-Runtime - and over
the new widgets also offering a new VB-IDE for that new compiler.

And I realized, that providing only the binaries "free for any
purposes" is not enough - if I want to reach the above goal,
I will have to open up the sources too (under LGPL), to gain
real community-effects (and to be able, to "put the work-load"
on more shoulders - and to address the "trust-topic" better).

Preparing appropriate "online-structures" for that "in the right
way" is highly important - and not an easy task - and the codebase
for the current toolset is not a small one (there are currently about
1.4MB of pure source-code-modules in *.bas and *.cls-files
for the RichClient-lib alone ... + about 300kByte of Demo-
Sources currently).
And the new widgets and the cairo-wrapper-classes will add
around 500kByte of additional source-code on top of that.
All the source-files will need proper beautifiying, more
verbose comments, proper LGPL-headers "on top" -
a new dedicated Server-machine needs to be "booked" and
set up over an "online-hoster" and a new website needs to be
prepared (Forum, Wiki-engine for the documentation, etc.).
I want to avoid, using sourceforge- or google-code-hosting
for all that stuff, since I also plan a dedicated VB-Client
for that project in either case (also available as VB-source),
which works against that online-host then (the online-machine
using the already available RPC-Classes at the serverside) -
and that should offer a much more comfortable and responsive
interface then - regarding Docu-Access/Editing, Forum-Functions
and Code-Contribution/Uploads than a pure Web-Interface.
A WebBrowser-Interface will then only reflect such content
(Forum and Documentation) in a "read-only way" - so we
will not have any spamming-issues and all that captcha-mess
to consider.

That's where I currently "stick", waiting for a larger "time-
window" beside my daily work, to prepare all that.

I know, these were proposed already some time ago - and
should be "out there in the wild" already for some months now,
but as already said, I'm doing all that in my spare-time, beside
my daily work - a larger timewindow (in spring 2009) was
passing by - and I've not (yet) managed, to finish the porting of the
already existing widget-classes from GDI-based rendering
to the new cairo-based rendering-engine which already works
very well.

So I've invested my smaller available "time-chunks" into the
RichClient3.dll over the last months at least, trying to react fast
to the incoming E-Mails regarding feature-requests and bug-
reports.
After all this is the base-library, everything else depends on
(also the new widgets) - and having it in a bugfree state as
it is now, is not the worst thing to start from.

I would appreciate, if the members of this group would
recognize it (the current toolset and the new upcoming widgets
on top of it) as what it really is (or want's to become):
An attempt, to move on (with) VB-Classic Code - and
not "just another 3rd party-lib, with the (hidden) intention
to make some money in the end".

Please be patient with me - you will get a much clearer picture
of all that, if you see the new widgets (incorporating the
RichClient3-toolset for databinding etc.) in action - will
try, to post the first working "enhanced Demo" (which
incorporates all the new widgets already) in form of the
just mentioned "community-client", which is then offering
a Forum - the Docu/Help Reader/Editor - and a VB-Source-
Viewer/Editor already.
From that point on, everything should move *much* faster,
the current "one-developer-only struggeling" becoming history.

Will try, to reach that state in late September 2009 - as it is
currently, I'll be busy with my daily-work-projects until August.


Olaf

Yep.

Because they are library specific and should be in a product support
newsgroup.  That way people can search the *one* place and find all the
different discussions relating to the product.  There's plenty of free open
source hosting that includes discussion and bug reporting etc; so why not
make use of them ??

As already mentioned - this library is not really "a product".
At least I'm not looking at it in that way.

It is publically available to the Classic-community - and
IMO belongs into the same category as the vbAccelerator-
Controls - or the CCRP-Controls or the NTSvc.ocx
(just to mention an MS-one). None of the above have
dedicated support-forums.

Not each and everybody is using such free downloadable libs,
but some have experience with it, so why not ask for correct
usage of these tools in a common VB-Classic group then.

And I already mentioned, that many users of the lib
are mainly interested in the builtin SQLite DB-classes.
So, is 'microsoft.public.vb.database' really only there, to
support questions, related to MS-SQLServer or the
MS-JET-engine exclusively?
I'd say no - questions, how to access MySQL-DBs from
VB-Classic or how to access *.dbf-files over FoxPro-
drivers or Oracle-Server-DBs per OleDB or ODBC are
(were) quite common in that group - so why not ask
questions, how to access SQLite-DBs (per VB ) in an
optimal way in that group too?

Yep - would be nice to have something like that
*in addition* - and I already wrote, that this is planned.

Thought, I already explained that in my last post.


Olaf

Show quote Hide quote Absolute nonsense. The CCRP controls did have their own support forum when
they were being worked on. They also included **source**.  you don't do
either.  So what you have is a proprietary product.. it doesn't matter if
you give it away or not.

OMG, Billy-Bullsh*t again...

They did have - they don't actually have...
And the CCRP-stuff was only mentioned as one among
other examples I gave you above - not that difficult, to
follow the basic-argumentation IMO.

Also wrong - not for all of them was source publically
available (at least not to me).
http://ccrp.mvps.org/index.html?support/faqs/source.htm
Maybe these restrictions were lowered later on - but not
sure about that.

How often do I have to repeat that for you - it will be opened
as soon as I find time for that - consider it done - I'd think
there's nobody in this group, who has the slightest doubt,
that I will indeed fulfill that promise, after mentioning it
here publically - there's some reputation to lose, if you
have that wording (yet) in your vocabulary.

Ok, you can call it any way you want to -
but that will not change the fact, that we will have a new,
modern widgetset on top of a capable infastructure-lib
available at the turn of the year - both parts available as
LGPLed Source-Code, including Demo-Apps.

Just watch - and thanks for pushing me - I need that
sometimes.


Olaf

Show quote Hide quote Well duh.  the CCRP site says " The CCRP support newsgroups have closed."
Like I said, they *did* have.  The web site also says all development has
stopped.


Yeh, bad choice of example then by you.  They did everything right. HTH's.
Most importantly they did set up their *own* newsgroups.


So you keep saying.  How long does it take to put up a project on codePlex,
Google Code, or Source Forge.  For someone who professes to be developing
"open source" and advocating it, you certainly are not following open source
norms.  Grab a project site, get bug tracking happening.  It's really not
that hard.  IF you are already distributing bits and "supporting" them in
these newsgroups you should be doing that as part of your sites project.
*Thousands* of other people do.

Oh closed..., so why not ask questions about the CCRP-Controls
now here in that group?
Why not ask questions about the NTSvc.ocx here in that group?
Why not ask questions about the vbAccelerator-Controls here
in that group?

Hope you got it now.

Nobody should have any problems here IMO, if such
questions to publically available (free, without any hidden
restrictions and "money-interests") VB-components come
up in a vb-general-discussion-group ... even *if* there
is a dedicated forum for such components - some questions
are of course better asked in these dedicated forums (if there
are any for these libs) and should be redirected then - but
some questions IMO better fit into the "common-
language-group" these free tools were written for.

Speaking for myself - I see this group as a technical information
resource, which is giving hints, how to solve "daily work problems"
in an optimal and efficient way (with the VB-Classic-langauge) -
and these ideas and hints can be deduced from the answers to
specific questions.
So, if a question - and the following answer(s) (no matter, if
the solution is achieved with "pure VB-Code" or with "not
that pure VB-Code, involving a nice helper-lib") gives me
some ideas, should the same problem occur to myself (later
on) - then what is wrong with that.
"Pure VB-Classic-Code" of course the preferred solutions -
but knowing alternative solutions, based on helper-libs which
maybe behave more stable than "pure code" (e.g. with
regards to subclassing) - or perform the same task much
faster (other algorithm, or compiled with an more optimizing
compiler, that not introduces other, larger dependencies) -
then - good to know...

["opening of sources"]
Yes, so I'm saying - and that should be enough IMO -
"a mans word", you know ... for people who don't have
"sold their soul" this term has yet some value ...

LOL - "MS-Bill" talking about OpenSource-Projects - and no,
a well working OpenSource-Project is not done with a simple
upload of a "bunch of code-modules" to one of these "fast-
food" code-hosting-sites.

It is all about (keeping up) *project-flow* - easy to follow, easy
to join, easy to contribute - meaning a nice "current tasks-view"
(with percent-progress) - embedded into a global release-
roadmap - with "check-in-points" for interested developers ...
each "SubTask" as isolated as possible in that "Project-ToDo-
Tree", with different responsible maintainers on each important
SubNode - clear interface-definitions beforehand for the
classes which need to be implemented - well working CheckOut/
Compile/Test ... DiffCheckIn/Review/AcceptCheckIn ... cycles
(based on a yet to be choosen SCM that plays well with VBCode).

Setting up such a project-client (+ defining the project-todo-
tree as granular as possible) and testing the "flow-cycles"
beforehand is a whole lot of work - and the current large code-
hosting-sites don't provide such enhanced stuff out of the box -
only the "rough main-structures" - not easy to enhance or adapt
to the special needs of a given project. Many of these sites are
slow, cluttered with advertising - all that can (needs to) be
avoided IMO - we have special requirements, since this is definitely
a special and complex project (we don't talk about just the
"opensourcing" of a simple helper-lib - we talk about a serious
attempt, to ensure the survival of the VB-Classic-language).

For example the sqlite-project has a nice *dedicated* site
and the project got already some awards regarding project-
flow and community-support (www.sqlite.org).
The site entirely written in C (all working at the serverside
against an SQLite-DB), no advertising - everything optimized
only for the kind of project they want/need to support.
And I think, we can do the same (or even better technically,
if we avoid a Browser-Client for all the "enhanced stuff in
write-direction").

Therefore a dedicated Project-Client, entirely written in
VB - that's the language each potential project-member has
experience with - everybody able to maintain and enhance
that Project-Client - no HTML, no CSS, no JavaScript-skills
are needed - the code-modules which make up that Client
are visualized and accessible in the Client itself (together with
all the other code-modules which the client is based on - as i.e.
the richclient-lib-modules + the cairobased widget-modules).
Very responsive such an approach - much shorter roundtrip-
times whilst working against the serverside compared with
a WebBrowser-Client.

There is a reason, why some OpenSource-projects succeed
and some don't - and I'm not that naive to think, that "just firing
up my code-modules into a public CVS" will be enough - that's
by far not enough.
There are many things which have to be set up and tested priorly -
and VB has some specialities which need to be addressed and
respected too - mainly the COM-interfaces and their IDs -
will need to find a way which makes it easy, to just checkout,
compile and test parts of such a large project-tree without Dll-
Hell- and BinComp-problems. It's finally not only the code of
the RichClient-lib which is hosted there - there is also the new
CairoWrapper-COMponent - and also all the new widget-
classes - followed later on by the codemodules for the new IDE
(making use of the new widgets), followed immediately by the
new Compiler-Codemodules, which are (need to be) tightly
integrated into the new IDE.

That's the whole reason, why I hold back what I currently have -
it needs to be adapted to and tested within these new project-
flow-cycles and -structures first, all structures wellthought and
implemented with the larger plan (the "global roadmap")
in mind - and I already mentioned, that I don't have that
larger time-window currently, to do all that "immediately",
just because a single person (which not even has an interest
in the success of that project) requires me to do so...

I'll probably need a full week "only with Paper and Pen" -
before I start to implement anything in this regard at all.


Olaf

Show quote Hide quote <sigh />  you really are unbelievable.  Let me say it again for you clearly.
CCRP had their *own* newsgroups.
This newsgroup is not for 3rd party controls or libraries. The people behind
the CCRP project knew that and did the right thing.

Again, if you truly profess to be developing an open source library, do so
using one of the open source sites that allow for bug tracking, discussions
etc, OR do so as the CCRP team did and set up your own.

This is rich. We've got a troll trying to
hijack a newsgroup by appointing himself
the edicate police.... On top of that, it's a
Microsoft lackey who's complaining about
non-open source tools.

What'llTheyThinkOfNext!  :)


Show quoteHide quote

By *All* I meant previous discussion on dhrich3 client already done here
anyways I got the point (*Concrete* one as well)

Yes users can libs where authors never even imagined

Yep its there I missed it

- but as
True! Document code is what code says can be done & how
Documentation however brings what developers digs out & does

Btw lack of strreverse in jet brought me here LOL


Our own web 2.0 infrastructure
(One word  ------- Excited)

But will require a bit of work to bring it up
& VB Classic is loosing developers everyday


leser souls like yours truly will be eager to answer others
with my coding experince of librarys

Just looked into the currently supported VB-Function-Set
that is available in SQLite-queries, but I've not included
StrReverse() currently in the wrapper-provided set.
But you can define your own userdefined (SQL-)Functions
within normal VB-Classes with a few lines of code.

It is basically comparable to an XML-RPC per Javascript
(which is the workhorse in each "web 2.0" scenario), but it
is working much faster (especially the serializing) - and it supports
compression and encryption and on top of that in a transparent
way too (no SSL-certificates needed at the serverside etc.).

One could already do that today with the RPC-Classes and
normal VB-Controls - but I want to demonstrate the new
(intrinsic) widgetset at this occassion within a useful Client-
Application then - just need some time for all that.

Not sure about, if it is such a large amount nowadays.
Those who wanted "to move" have already done so -
those who decided "to stay" are doing so too - we
have at least 10 years from now on - more than enough
time IMO and I'm pretty sure, in already 2-3 years we have
something, which is attractive and worth's considering a
"switchback" maybe. ;-)


Olaf

To my understanding cSimpleDOM can parse an xml string

but a element cannot be edited & xml saved back as in MSDOM

& getElementsByTagName sort of specific node recalling is not available

Yes, and that with support for all the different encodings
(respecting the different BOMs and of course also the different
lang-IDs) - as well as CData-Sections, etc.
Mostly 2-3 times as fast as MS-XML, especially on larger
XML-Content.

Yep, I've concentrated my efforts on the correct parsing for
all the different encodings - offering the parsed contents over
the DOM then as properly translated VB-UnicodeStrings.

The XML-Write-Direction is pretty easy to code yourself - just use
(joinable) StringArrays and fill in the needed TagNames with the
correct Opening- and Closing-Chars per normal String-Concats.
Correct Element- and Attribute-*Content*-Encoding is supported
too over cSimpleDOM.EncodeXMLTokens(). Really not
that difficult, to fill-in your own (Sub-) Node-Structures that way.

But *direct* write-support on the DOM-Nodes would be nicer
of course, agreed - but then the SimpleDOM would not be that
small and "simple" anymore - and also not that fast (also taking
up more memory).

No, you will have to loop over the DOM - and check for the
TagNames in your own If Then or Select Case-constructs (and
to speed things up, you can limit that to the Element-Hierarchy-
Level(s) you have an interest in).
That works really fast - and basically the MSDOM has to perform
such a loop internally too, to hand out the appropriately filtered
Element-lists to you - you can achieve the same thing with a small
(generic) function, which adds the found Elements to a finally
returned cCollection or cSortedDictionary (per Element.Clone).

I've not included that into the library, because in the few scenarios
I'm using the SimpleDOM, I always had more complex-search-
criterions to cover - and I usually resolved that with only one
"loop-through-pass" for all the different criterions at once
(by direct notation of the comparison-ops as normal VB-Code).

cSimpleDOM is thought for simple scenarios - for more complex,
full blown XML-functionality you can use the MSXML-COM-
Classes any time - but for smaller use-cases - as for example
parsing an XML-serialized Widget-Hierarchy to recreate
(reinstantiate) a correctly filled up cForm, the SimpleDOM
fits perfectly - without needing that larger MS-dependency.

Olaf

best way to write a VB-app with several languages
VB Express and VB files
Is my VB6 app form open?
ListBox - Limit Selection Rectangle Width
Keeping 2 listboxes in sync - VB6
Best method to have 2 checkboxes for 1 item
array dimensions and size error
In-Process and Out-of-Process
Command Line
How can I use these files in VB6?