Topic: Group Project: Change item(s) to Layer [Discussion]

[dgorsman]

OK, cool.  I'll have a look back at the entire discussion(s) to see you guys are structuring this (SVN?)

I'm thinking a very minimal modeless form with no title bar, displayed at the cursor location, and utilizes a MouseMovedOff event to close.

When I get something working I'll post an example . . ..

Once things get spinning, let me know - I'll see about setting up an ODCL branch on the repository.

[Chris]

just throwing out an idea here, so dont shoot me.  I'm not that familiar with ODCL (alhtough I have downloaded it and intend to learn it at some point)  would it be possible to have a check that if the user's machine contains the runtime, it would use the ODCL box, and if not use the standard DCL box?  Or is that just pointless?  I assume that ODCL offers more abilities than standard DCL.

[Chris]

I apologize Chris; I totally missed your question about the old or new help docs...I didn't mean to.

here's how I see it; you have more to say than I do about the docs because that is an area of development that I'm not that good at. however when I think of development documentation I think of the BSD developers. go to NetBSD.org and look for the manual. it is HUGE. I've heard that they spend 2 hrs on docs for every hr of coding.

we can toss around ideas about any style you like.

EDIT:
Here is a direct link to the NetBSD Guide (NetBSD is an operating system if you didnt know).
[ http://netbsd.org/docs/guide/en/netbsd.html ]

Ok, I got it, I was thinking something fancier, but I see how the formatting is.  I can use the help for Virtual Box as a base, as they also have theirs in CHM format, and follow this same style.  either way, it doesnt really matter, as long as we aren't changing it after we get going.  It is a real pain to go back and recode stuff so it all matches.

[Lee Mac]

just throwing out an idea here, so dont shoot me.  I'm not that familiar with ODCL (alhtough I have downloaded it and intend to learn it at some point)  would it be possible to have a check that if the user's machine contains the runtime, it would use the ODCL box, and if not use the standard DCL box?  Or is that just pointless?  I assume that ODCL offers more abilities than standard DCL.

These echo my thoughts, since I also don't use ODCL 

Or even, just have two programs, one using DCL, the other ODCL - you would only need to swap the DCL modules.

[dgorsman]

just throwing out an idea here, so dont shoot me.  I'm not that familiar with ODCL (alhtough I have downloaded it and intend to learn it at some point)  would it be possible to have a check that if the user's machine contains the runtime, it would use the ODCL box, and if not use the standard DCL box?  Or is that just pointless?  I assume that ODCL offers more abilities than standard DCL.

These echo my thoughts, since I also don't use ODCL 

Or even, just have two programs, one using DCL, the other ODCL - you would only need to swap the DCL modules.

Thats one of the features of SVN.  You can maintain different development branches, with the capability of merging them back into the trunk later.  As an example, I used to actively contribute the MegaMek project over on SourceForge.  They have a "stable" branch and a "dev" branch; "stable" is stable but somewhat out-of-date, while the "dev" branch has a lot of different updates applied from contributors which may or may not make it to the next stable release.

This is why I put the UI as a separate module here.  That way it can easily be "branched" to provide an ODCL branch, or even a managed .NET DLL branch, in addition to the conventional DCL in the trunk.

[JohnK]

Wouldn't it make more sense to:

• Check validity of selection as it's executed (eg. if or cond)
• create layer list and feed it to dialog selection
• iterate through selection set and put objects on defined layer

... <snip>...

Yeah, that does make more sense. That would make error trapping a bit easier (not that it was going to be difficult to begin with). ...<snip>...

What are the opinions on alanjt's recommendation?

[alanjt]

Wouldn't it make more sense to:

• Check validity of selection as it's executed (eg. if or cond)
• create layer list and feed it to dialog selection
• iterate through selection set and put objects on defined layer

... <snip>...

Yeah, that does make more sense. That would make error trapping a bit easier (not that it was going to be difficult to begin with). ...<snip>...

What are the opinions on alanjt's recommendation?

I'm He's a genius! 

[JohnK]

Yeah `genius'. Although, you may not be able to fit through doorways with that giant head...then you would be stuck at work.  Yeah, `genius'.

[Lee Mac]

Wouldn't it make more sense to:

• Check validity of selection as it's executed (eg. if or cond)
• create layer list and feed it to dialog selection
• iterate through selection set and put objects on defined layer

... <snip>...

Yeah, that does make more sense. That would make error trapping a bit easier (not that it was going to be difficult to begin with). ...<snip>...

What are the opinions on alanjt's recommendation?

I'm game

[alanjt]

Yeah `genius'. Although, you may not be able to fit through doorways with that giant head...then you would be stuck at work.  Yeah, `genius'.

LoL, very true.

[jbuzbee]

OK, I've had some time and have come up with three options:

Option 1: Typical Modal Dialog Box
The user would select a layer to transfer the Object to, the Dialog would close with the user proceeding to next select the object(s).



Option 2: Modeless Dialog Box
This Dialog Box would remain "Open" allowing the user to run the command on multiple objects.  Select a layer in the list box and then picking the "Select Object" button the focus would be shifted to the drawing space to, well, select an object(s).



Option 3: Popup Modeless Form
This very simple form would "pop-up" at the cursor location.  This would make a good toolbar button.  Once double-clicking on a layer, the form hides, and the focus is back to the drawing to select an object(s).  If the user decides to cancel the command, once the mouse leaves the form it hides.



All forms allow resizing and the last layer selected would be saved to the blackboard to be selected the next time the form is shown.  The modal form is the easiest to impliment with something like (setq layerName(KWIP:SelectLayerForm)).  The modeless forms will take a little bit more coding, and may need to be the main calling function (command).  I'm experimenting with that now.

The Help System: if you guys want to go HTML (that's what I use) I can provide a simple modeless OpenDCL dialog that displays HTML pages.

jb

[Chris]

It depends on what you use to create them.  If standard dcl can only handle modal dialogs, then that is what those users would use.  If you have opendcl, I would assume option 2 and 3 were created using it, so users could choose either one.  Otherwise, I'm partial to option 2

[jbuzbee]

Oh yeah.  I forgot about that - my bad Lee, sorry.  OK, so ignore #1.

[alanjt]

I like option #3 the best, but it would need to display at the cursor instead of at the toolbar or it would be no better than selecting objects and changing their layer with the layer pulldown.

[jbuzbee]

That's the way it works: if you type in "LL" (the shortcut for the really long command name) the form displays at the cursor.