Main Site Documentation

Hit the Limit



A single feature away from production release Pyxis 2 has hit the limit of the maximum allowed library size in NETMF. Which, mind you, is smaller than the space available on the Cobra/CWX by a good amount.


So now I’m going to have to split up the assemblies a bit more. So much for compatibility between beta & production releases.



Max allowed library size?

What exactly do you mean? Library can mean a number of things. Do you mean the assembly size?


NETMF hap has a limit on the maximum allowed bock size. This is nothing that most users can ever need to worry about but some of us are extremely (creative) skyeworks to make a design that is big enough to hit the limits…

…to me, this is a “good job” skeyworks lol


Yeah, apparently such a thing exists for NETMF. Pyxis 2 is sitting at 50 classes, 47 resources and 16,605 lines of code. Adding a single extra line results in an MMR error. Any line at all.

Time to do some serious architectural work on Pyxis.


@ Gus, Thanks! Now let’s see if I’m creative enough to work around this. The problem with breaking things out is avoiding cyclical dependencies. Controls require the Kernel and the Kernel has a few internal screens which require the Controls.

That was done to avoid having a bear of an install where the “Apps” required to run needed to be either copied out of EEPROM or downloaded from the web for Pyxis to start.

Gimme time, I’m sure I’ll come up with something…


Can’t you do the implementation of f.e. the GUI (buttons, trackbars, etc) by using RLP and write managed wrapper classes for it. It will run faster and would free more resources I think.


RLP is not available on Cobra or really anything other than ChipworkX so it would not be a good option. Otherwise I would have done so long ago. Thanks for the idea though! ;D


Yes, but the EMX is planned target for Pyxis and RLP on the EMX is not an accessible option.


Actually [italic]everything[/italic] is a target for Pyxis; which is why I play as nicely as possible.


I took a quick look at your code (and am still busy :p).

I have one remark for now: don’t implement IControl as an interface but as a class.

When I check f.e. the combobox class and checkbox class I see a lot of the same source code (Widht, Height, X, Y, Visible properties, etc… this is all the behavior of a Control and only needs to be implemented once).


Also, you don’t need to keep xOffset & yOffset, make x & y always the offset to the parent. When you want to determine the screen x & y you can add the parent.X to the child.X (this way the screen x will by calculated by recursion)


Wouster, this is another one of this workarounds required by NETMF. In order for those controls to be accessed across AppDomains they have to inherit from MarshalByRef.

They used to work as inherited objects from UIControl but then couldn’t dual inherit from MarshalByRef. I’m looking into options now. Keep the ideas coming.


RE: Offset; these are actually more needed than you realize, because of AutoScroll (which isn’t available in your beta but is in my RC version).


And what if the Control class inherits from MarshalByRef. And the checkbox inherits from Control? Doens’t that work with AppDomains? (Never went that far on my Cobra since I don’t have a LCD etc )

And as I said, you only need the keep offsets, no real screencoords. But then I see you render to a single bitmap so this could idd slow it down…


@ Wouster, that’s getting close. I can have say Label inherit from Control which inherits from MarshalByRef but that leaves me wonder if then accessing a method/property that is present in Label that isn’t present in Control would that cause a major failure. Probably. I may test it soon. I’m working down a different avenue at the moment.


It looks like with some of the changes I’ve made I should actually be able to pass the controls as Serializable instead of having to inherit MarshalByRef, which will save me plenty of code space.

But that’s only going to be part of the solution, time to really streamline this thing and get it ready for production.


One thing I don’t like either is this code in your virtual keyboard:

// Row 1
            string[] letters = { "Q", "W", "E", "R", "T", "Y", "U", "I", "O", "P" };
            int y = iStartY;
            int x = (int)((AppearanceManager.ScreenWidth - (28 * letters.Length)) / 2);
            int farLeft = x;
            int i;
            for (i = 0; i < letters.Length; i++)
                button btn = new button(letters[i], x, y, 25, 25);
                btn.tapEvent += new OnTap((object sender, point e) => bindKey(btn, btnShift));
                btn.font = fnt;
                x += 28;

Implement the keyboard as one image in resource. And just check the coordinates where the user clicks. Less memory, faster and you can create a nicer keyboard with some photoshop skills etc (or just take a screenshot from the iPad, hehe)


That’s been sitting on my low priority feature list forever. There are more important things at the moment but, rest assured, it will be addressed…eventually.


Ok I’ll let you do your work :wink:

It’s just that, when hitting limits, I prefer losing weight instead of wearing a larger t-shirt :smiley:


We’re doing both. Here’s a peek at the new Pyxis 2 architecture:

GUI Assembly [italic](Dependencies: Messenger)[/italic]

  1. Houses all controls
  2. Controls derive from base class and are serializable
  3. Knows screen details (height, width, depth, orientation)
  4. Is static
  5. Houses the screen buffer bitmap (public and static)
  6. Knows which form is active

Application Manager Assembly [italic](Dependencies: Messenger, GUI)[/italic]

  1. Loads and Unloads applications
  2. Updates the GUI’s active form as needed
  3. Keeps a list of applications running in indexed order of last accessed
  4. Static & Public

Hardware Manager Assembly [italic](Dependencies: Messenger)[/italic]

  1. Contains all the current “Manager” classes in Pyxis 2
  2. Public/Static
  3. Handles usage of managers that must not be static, such as the DeviceManager.

Messenger Assembly [italic](Dependencies: None)[/italic]

  1. Static/Public
  2. Used to send messages between different areas of Pyxis