Cherry Audio Forums

I am in the process of designing and publishing my first module. I spent several days drawing out my ultimate module with as many features as I could imagine. I am so pleased to not have any crashes in Designer during that several days. The code editor feature is quite simple, I dont get any kind of autocompletion, despite enabling that in preferences and then restarting, but still, in many tests of my module, the designer only seemed to get tripped up a couple of times about whether the module was still in the debug console or not, but otherwise, very stable.

In posting some demos of what I have completed with my module so far, I realized its current version is worthy of being a releasable module. So the decision had to be made, hide all the unimplemented UI with SetVisible(false), or make a copy of the project and delete the unneeded UI stuff and related code? I decided it was simpler to fork my code to a new project.

In the process, of deleting unused UI elements, and adjusting the code, I later realized I deleted some controls that would be really easy to implement. But because the project file is a binary file, I don't see any easy way to add back the 16 UI controls, and avoid going through all the renaming, etc.

If the VM project file was more like XML, it would be trivial to cut and paste visual elements between my projects.

This creates a simple issue for source code tracking, similar to the problems in maintaining .FLA flash project files. Minor tweaks to positions of elements just show up as the entire binary file differing between versions, with no clue as to what changed. At least with VM, if one always does a build of the project, before checkin, the side file of Java code can be checked in and can be diffed between versions. But, eventhough that will help highlight UI changes between versions, there is no easy way to edit the module file to cherry pick some changes, without going into the visual UI and manually tweaking each control individually.

Flash had another file format called .XFL that separated the things that could be represented in XML into separate XML files (DOMDocument.xml, MobileSettings.xml, PublishSettings.xml), and also separate binaries and .AS code files. The .XML files that record visual designer info have the problem that they are very noisy with their "lastModified" fields, when no other field of the given element had any change in value. So diff'ing them was not optimal.

Right now replacing a whole series of toggles with closely spaced toggle buttons.

It sure is tedious trying to get all these to lineup just right. It is especially hard to make sure all the text lines up properly on top, and its tough to select the button under the text when the buttons are small.

Saving and reloading the project file appears to have randomized the tab order of my buttons and text objects. They were good when I created the first group, and when I duplicated them. The tab key would jump from text label to button, then to the next text label, then to its button, etc. But after the save and reload, the tab order is all messed up.

Things that help:
* zooming in the designer helps
* making the height of the text labels smaller. The height can apparently be less than what is needed for the font, and they still display.

If the project file that drives the visual editor was in XML, it would be easy to exit Designer for a bit, load the project file into an text editor, do some touchups to the positioning XML, save, and then jump back into Designer to continue on.

I think most developers create components that require a large degree of repetition and accuracy programmatically. I certainly do as it's a hell of a lot quicker than doing it by hand and of course easier to modify. It also simplifies the code.

I think what Colin is saying is that if you create all your controls in Initialize() instead of in the graphic designer, you can edit them in code at will.

Reid