Alternatives
in [Visual Basic]
|
From: C Kevin Provance on 24 Jan 2009 00:57 "Bill McCarthy" <TPASoft.com Are Identity Thieves> wrote in message news:u3YNbfefJHA.5540(a)TK2MSFTNGP06.phx.gbl... | Huh huh. And Jabaco does NOT provide that at all. Vb.NET is miles ahead of | it on that front. IF you think VB.NET is not good at that, then Jabaco is | beyond hope. You need to get that .NET disk out of your @$$ and step back into reality. Douche.
From: Ulrich Korndoerfer on 24 Jan 2009 17:18 Olaf, did you read my post? -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
From: Schmidt on 26 Jan 2009 18:01 "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> schrieb im Newsbeitrag news:uaKA3GnfJHA.4868(a)TK2MSFTNGP05.phx.gbl... > Olaf, did you read my post? Yes, I've read it - sorry for not responding for that long - but it had such a "frightening size" ... ;-) Maybe a short-reply will do too, if you don't mind. Your infos about the UPX-stuff are convincing, so - thanks for pulling that "out of the Web". Maybe I should simply offer two zipped versions of the framework then, and write some comments about the version, which contains the UPXed binaries. As said, my load-tests here (I usually work against a network-share, which hosts my test-projects) are somewhat better than with the non-upxed versions, and normally one will not see all that much of a difference regarding mem-consumption, because MultiProcess-usage against the framework-dlls sitting in an App-Folder is probably not the main- use-case. As the main-argument against "upxing" probably remains your mentioned "nervous behaviour" of some of the cheaper Virus-Scanners when they find upxed stuff. Think with the parallel-offering of both variants everyone can choose what he wants to use later on, without the need to upx or test the "plays together-behaviour" of the upxed versions himself. What I do know is, that - when you place upxed binaries in a Zip, you gain some other 20% or so regarding the download-size (at least for many VB-compiled binaries this holds true, because the UPX-packer apparently leaves out some parts in the PE-structure then and in compressing executable code it does its job better than the "more generic" Zip-Inflate-Algo). --------------------------- Regarding Cairo: I was playing "ping-pong" with Jeremiah the last week - and his Form-engine can now already render the first ported Cairo-Widgets, but for a while that worked only on my own machines, which we already tracked down to a missing msvc90rt.dll. This dependency was introduced by the cairo-satellite-subprojects (libpng.lib and zlib.lib) which I forgot to set the /MT- C-compiler (linker) -switch too. The new, recompiled cairo2_engine.dll binary size is now larger of course (ca. 830kB, upxed ca. 370kB) - but not all that much. I will post the source of the first cairo-ported widgets to you, when I'm done with the port of the widgets which handle the TextEditing, since you had an interest in them - currently I'm yet at the Button-Widgets (including the Check- and Option-variants) - and thereby optimizing the Cairo-Wrappers-interfaces especially for less needed lines of code when writing drawing-code for the widget-implementations. That cycles currently too much back and forth - so not the right time yet for something like code-beautifying - the dust has to settle a bit first. [Coding rules:] Definitely important - but let's talk about that, when the project is announced officially - and yes, I know that my style is "no style at all" - but at least we can copy examples from it for new contributors in a section: "what you definitely shouldn't do:" <g> [Internationalization/Localization] Nice ideas (already archived here <g>) - but not (yet) the right time IMO, to incorporate that - although we also should respect something in this regards soon. But I want to keep the first incarnation of the widgets- project yet simple, to make it easier for potential contributors, to "dive in" - I'd love to integrate the internationalization-support - and also the themeing- engine support, as soon as there's already some experience there in the "community" - regarding the understanding of the engine - and how to efficiently implement new widgets. Let's get used to the new model first over a few months. But then we should integrate this "enhanced stuff" sooner than later, before the widgets get to a level, which makes such a change more difficult. [Actions, Statemanagement and Transitions] Yep - all the techniques which are required in clean MVC (Model View Controller) or MVP (Model View Presenter) scenarios. But here I'd like to follow the same "rule" as with the topic above - let's wait a bit with that enhanced stuff. Our primary goal should be, to not make an "elitists" platform for "freaks only" - it should be an easy to use environment, suitable also for beginners who already know the base- principles of VB5/6 (Forms, "normal" Events, etc.). What I've already builtin is something, which allows an Event-Bubbling back over the Parent(s) - each Parent can then decide, if he wants to delegate the Event one Level up, or simply does nothing in this regard - and then the Event only occurs in the first Parent (of the raising Child). This Event looks like this: Event ChildStateChanged(Sender As Object, StateInfo as Variant, _ StateInfoEx as Variant) And then there's also the cEventCollection-Class inside dhRichClient.dll - which allows LateBound Events - I just implemented a simple Control-Array-like approach using this Event-Conatiner in combination with a group of OptionButtons - works nice so far with only a few lines of code. So with a combination of the just mentioned methods, we will not have to dive too soon into that advanced Event- and State-Model, which we could implement later on - and then not based on VBs Std-EventMechanism, but using an Interface-based Event-mechanism which should work faster. But maybe the stuff I just mentioned will already fullfill most of the advanced requirements - and "normal" Widget-Events are of course also there, directly at Control-, respective Widget-level - those who already have implemented a VB-UserControl will see the same things as they were used to within VB-UserControls, only that everything works class-based. Regards, Olaf
From: Ulrich Korndoerfer on 28 Jan 2009 21:19
Hi Olaf, Schmidt schrieb: > but it had such a "frightening size" ... ;-) Some 300 lines frigthen you? :-) > Maybe a short-reply will do too, if you don't mind. That's ok. [UPX] > As said, my load-tests here (I usually work against a > network-share, which hosts my test-projects) are > somewhat better than with the non-upxed versions, > and normally one will not see all that much of a > difference regarding mem-consumption, because > MultiProcess-usage against the framework-dlls > sitting in an App-Folder is probably not the main- > use-case. You forgot that dll sharing is still "en vogue". Not in every case it makes sense to deliver needed dlls as "local" dlls in the applications folder. Eg. for little desktop gadgets like clocks, rss readers, (audio) stream players etc. it would make sense to share the dlls. They show their GUI on the desktop, startup when the system starts up, and therefore eat ram all the time. Now when the dlls are upxed, each of this little helpers loads all needed dlls as private copy. > --------------------------- > Regarding Cairo: > ... > I will post the source of the first cairo-ported widgets > to you, when I'm done with the port of the widgets > which handle the TextEditing, since you had an interest > in them - currently I'm yet at the Button-Widgets > (including the Check- and Option-variants) - and thereby > optimizing the Cairo-Wrappers-interfaces especially > for less needed lines of code when writing drawing-code > for the widget-implementations. > That cycles currently too much back and forth - so > not the right time yet for something like code-beautifying - > the dust has to settle a bit first. Ok. > ... > [Internationalization/Localization] > Nice ideas (already archived here <g>) - but not (yet) > the right time IMO, to incorporate that - although we > also should respect something in this regards soon. > > But I want to keep the first incarnation of the widgets- > project yet simple, to make it easier for potential > contributors, to "dive in" - I'd love to integrate the > internationalization-support - and also the themeing- > engine support, as soon as there's already some experience > there in the "community" - regarding the understanding > of the engine - and how to efficiently implement new > widgets. Let's get used to the new model first over > a few months. > But then we should integrate this "enhanced stuff" sooner > than later, before the widgets get to a level, which makes > such a change more difficult. That was my point. I just wanted to remind you, that you keep in mind that such things should be added and that it may be probably to late later to be able to integrate such things with small effort. > ... > [Actions, Statemanagement and Transitions] > Yep - all the techniques which are required in clean > MVC (Model View Controller) or MVP (Model View > Presenter) scenarios. > But here I'd like to follow the same "rule" as with the > topic above - let's wait a bit with that enhanced stuff. And same concern as from above: if the code is to advanced, it may be not easy to "learn new things to the old horse" ;-) > ... > What I've already builtin is something, which allows an > Event-Bubbling back over the Parent(s) - each Parent > can then decide, if he wants to delegate the Event one Level > up, or simply does nothing in this regard - and then the > Event only occurs in the first Parent (of the raising Child). > This Event looks like this: > Event ChildStateChanged(Sender As Object, StateInfo as Variant, _ > StateInfoEx as Variant) Should'nt there be bidirectional bubbling? Eg. if an option button in a option group gets checked, it firstly (before it changes its state) should notify the root, then the childs from there bubbling down until it reaches the option button himself. So parents (eg. the grouping parent of the buttons) can decide what to do (eg. uncheck another button). And afterwards bubbling up from the button to the root. > > And then there's also the cEventCollection-Class inside > dhRichClient.dll - which allows LateBound Events - > I just implemented a simple Control-Array-like approach > using this Event-Conatiner in combination with a group > of OptionButtons - works nice so far with only a few > lines of code. > > So with a combination of the just mentioned methods, we > will not have to dive too soon into that advanced Event- > and State-Model, which we could implement later on - > and then not based on VBs Std-EventMechanism, but > using an Interface-based Event-mechanism which should > work faster. > But maybe the stuff I just mentioned will already fullfill > most of the advanced requirements - and "normal" > Widget-Events are of course also there, directly at > Control-, respective Widget-level - those who already > have implemented a VB-UserControl will see the same > things as they were used to within VB-UserControls, > only that everything works class-based. I do not know your implementation. That may be sufficient, of course. Looking forward for the first code to see myself ;-) -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.proSource.de/Downloads/ |