This is a new feature request. I'd like to see a new command, or a modification to the MoveObject command, so that objects or object groups could be moved from one page to another at runtime.

The reason is this: In order to create elegant interfaces I have layer after layer after layer of invisible objects on the main program screen that I turn on and off as needed. Some are semi-transparent and as large as the entire screen. This prevents me from having to have multiple pages that are only slightly different and prevents large scale duplication of objects on other pages.

The down side is that when I open NeoBook to edit the program, I have to manually remove these object layers one at a time and move them to other pages so I can work on the main page at the bottom of all that. If I was able to move objects between pages at runtime, then the object groups could always be stored on their own pages, and they could be moved to the main page and made visible when needed.

An alternate approach would be having a new page type that acts like a transparent layer. The order the "page layer" page occurs in the editor would determine its elevation in the layer stack over a defined "main" page. You are already doing this with the "Master Page / Regular Page" relationship. This would be like having more than one page at a time visible over the master page. It could be a parameter of each page such as a checkbox like "[ ] Transparent Layer." But I suspect that adding a "page" parameter to the MoveObject command would be much easier.

Anyone who thinks this would be a good thing chime in with a "Can I have an A-men" or something.

Neosoft Support wrote:Could you place objects off to the side outside the work area for editing, then move them into position at runtime with MoveObject?

I have done that with some objects, but there are a lot of them now and screen real estate is limited so they end up on top of each other again. And some of them are full screen size so I can't see all of them when they are visible. That means moving them around again to be able to edit them or anything underneath.

As it is now I have a series of empty pages, each named the same as one of the invisible objects. When I open the editor to work, I have to select the one on top, click Cut, then go to its labeled page and click Paste. Back to the main page I repeat the process for each object and page until I have the main page layout exposed. Then I can work. In order to test my edits, I have to schlep all the objects back onto the main page. If I had a MoveObject command that was interpage capable, then I could leave the objects on their dedicated pages and just pop them onto the main page at runtime. With such a MoveObject capability, programmers could mix and match objects as needed rather than duplicating them on various pages.

Originally, I tried to deal with this by opening the objects as frameless CustomWindows and precisely position the window. But if the user moves the program window, then the windows don't move with it and the whole thing goes to pieces. Using object groups keeps the group positioned in the program window, and they can be partially transparent and have shadows.

As for layered pages, you can imagine how this can also be solved by having transparent pages that can be turned on and off at will, or moved up and down in the stack. Parameters at edit time could be; Visible, Transparent/Opaque and Elevation. The same parameters could be changed at runtime.

Sounds like you're working on an extremely complex program. This issue hasn't come up before, but there are definitely many uses for moving objects between pages. I will add this to the list of things to consider for a future update.

You wouldn't think it should be. It is just a database to manage passwords and financial accounts, but I made one choice that has driven all the complexity. I decided to have the internal stored data encrypted, field by field, instead of relying on an overall encrypted database. Handling and displaying the data while it is encrypted makes it very complex. The other thing is that I want a very elegant interface with sections that fade in and out and things that get covered up when I don't want them used and so on. This is probably going to be my last commercial software attempt and I need it to be good in order to compete with the current flock of password managers. Mine will be a paid program competing with free and paid password managers by large companies. I have to knock it out of the park or I might as well forget it.

there are definitely many uses for moving objects between pages. I will add this to the list of things to consider for a future update.

If the page is resized, the objects can be placed only on the left and top of the page.

LOL ... I hadn't even thought about resizing the application. My interfaces are always so ... "graphically robust", for lack of a better term, that I never use resizable windows. resizing would hose them up beyond belief.

Still, if the app is resizable, then the object brought on screen from another page is still useful. You would just have to add code to reposition the object relative to another existing object or the screen corner, and then make it visible. In the case of having pages that can become visible, you still have to deal with adjusting the position of objects on that page relative to the newly resized window. It's a toss up. Either solution still works. You just need adjustment code for resizable apps.

I found that if I originally place an object outside (to the left) of a page's view area, I can then make it appear in any page. Of course it has to be moved into the exact view area desired with MoveObject and ObjectToFront... but it shows up on any page I want.