"Joe Programmer" <[EMAIL PROTECTED]> wrote in message news:68014@palm-dev-forum... > > --- "Palm" wrote: > > I beg to differ with you on this. I don't > > think limited memory or lack of multitasking > > has anything to do with the lack of > > components. I think common components would > > actually save memory ... > > --- Joe Programmer wrote: > > (various statements calling into doubt whether > > or not memory would be saved) > > --- Mark Ginsberg wrote: > > Well, I think you snipped the last part of > > the original question which said "It could be > > something like charts or other such things > > used for display puposes as on desktop > > applications". I interpreted that to mean > > that the original question was for "something > > like" activex/ocx controls. > > That's exactly what I was talking about. If you want > to create a pluggable architechture on top of the > current OS which allows programmers to create > something like ocx controls, you need to add a bunch > of code to the OS or create and install a code library > on the device. This is exactly what AppForge does so > you can create code in VB and run it on a Palm OS > device. Their helper app is called booster.prc. > AppForge Booster Version 2.0 uses 676 KB of valuable > Palm memory. *After* installing it, you get to use > all of the included controls in your AppForge prc. > > If you are already building a very large application, > this can be a wonderful thing. However, there is a > significant overhead.
I'm not familiar with the product that you mentioned but I'm sure that a large part of the reason for the size problem is that it supports VB. To support VB you probably have to implement the COM system, the ActiveX interfaces required for the controls including the automation interface and lots of stuff that I can't even image right now. That's a bunch of code. What I am talking about is enhancements to the OS and/or developer tools for a better runtime loading mechanism (like DLL's) so developers can distribute object modules instead of source. If we can also get a common object module interface (maybe something that looks like COM), and write the system extensions in C++ that would be even better. I can't imagine to overhead to such a system would be more than 10K-20K. The OS already supports extension libraries - I'm just asking to make it easier to write them and if possible the ability to write code in C++. It's not like the OS has to handle out-of-proc marshalling of data or jumps to code on other machines like DCOM does. All it has to do is in-proc jumps. I don't know enough about the Palm OS internals to say but I assume it shouldn't be too complicated to be able to route events to the code included in a extension library (if it you already don't have that feature). Once you have those two pieces in place all you then need is a clean way to dispatch events to the code from your event loop and you're set. Isn't the beginning of this kind of thing implemented for gadgets? I understand the problem and I agree that bloating the OS 676KB isn't the best way to go but even if my 10-20K estimate is low I think that a forms based tool, without the ability to easily add new controls (especially given the pretty sorry state of the built-in controls) is unforgivable. Mark Ginsberg DependTech,LLC -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
