TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: JohnK on March 30, 2011, 07:20:24 PM
-
Idea/Concept/Overview:
DESCRIPTION:
----------------
This project will allow the end user to select an item (before or after tool is called) and change the item(s) selected to a layer of the end users choice. Choice of layer will be made via a dialog box (list box, with an Ok and Cancel button).
MEMBER RANKS:
----------------
Boss:
Decision Maker
Lieutenant:
Package Assembly
Assassin:
Documentation editor
Soldier:
Coder / Documentation creation
CRITERIA:
----------------
N/A at this time.
Please make your suggestions for any changes, additions, etc. for anything listed in this post (add to the criteria, make changes to member ranks, change the description).
Please note:
1. I imagined that after this tool was created we could have another or additional tool to change everything on the selected items layer to a new layer (just an idea).
2. I realize this project can be done by one person but the act of working in a group is my overall objective (It will not only strengthen member ties but allow others to learn).
3. I would imagine that after this step we can create a sign up sheet for ANYONE who wishes to contribute.
-
Sounds good: A simple but useful tool, perfect for use in a library.
What language will this be coded in (AutoLISP, Visual LISP, or something even more exotic)?
What's the Lieutenant supposed to do?
dJE
-
either or both.
not sure yet; we should discuss if this should be item #1 in a suite of tools and\or if this needs something like an installer. ...?
-
*Se7en checks to see if his profile says: "Ignored by: * members"*
So whats wrong now? No comments/critisisms/thoughts...nothing?
Let's try this (open this thread up):
Is there even a chance at a Group project? What are the problems with a group project? I thought the problems would be "time" and complexity" so i tried to think of a very simple project where people would only have to contribute a few lines. What has to happen to get a discussion started (I will even promise not to contribute if that helps; i dont understand [does everyone hate me that much]).
-
[Says the monkey in the peanut gallery who is completely devoid of ANY coding skills.]
"I'm waiting with bated breath, aquiver with the anticipation of pilfering the results and learning something in the process."
[/monkey shuts it]
-
I just don't want to do much Lisp anymore. I'm pretty comfortable with the knowledge that I have, and would rather expand my knowledge with C#. That is why I don't participate in the Lisp forum that much anymore. Plus those people that do answer the questions seem very capable.
-
Holly macarroni and cheese!!!
What it is lisp ? by the way ? :-o
:-P
I just don't want to do much Lisp anymore. I'm pretty comfortable with the knowledge that I have, and would rather expand my knowledge with C#. That is why I don't participate in the Lisp forum that much anymore. Plus those people that do answer the questions seem very capable.
-
I'm not that excited about Lisp either but I'm really trying to help theSwamp become a better place. sh|t, i even tried to develop/extend a new tool for the comunity to facilitate the group development process but even that turned out to be a major faceplant.
Im just trying to help this place become the best place on the net for help/tools/etc.
barc, you most certianly can help if you want even if you dont know any lisp; you can come up with ideas/criteria/documentation/etc. ...plenty for anyone to do.
-
Holly macarroni and cheese!!!
What it is lisp ? by the way ? :-o
:-P
It's a language way above your abilities LE.
:-P
-
That is why I asked what people would want in an xref suite. To help out the community. Also to learn.
-
Idea/Concept/Overview:
DESCRIPTION:
----------------
This project will allow the end user to select an item (before or after tool is called) and change the item(s) selected to a layer of the end users choice. Choice of layer will be made via a dialog box (list box, with an Ok and Cancel button).
Okay a suggestion, maybe this is too soon for this level of detail but....... We frequently incorporate vendor drawing information in design drawings, can the function be so designed to pull layer information from a separate template file or a standards file, then if that layer doesn't exist, create it and set parameters, if it does exist giove the option for using current settings or replace with template/standards settings?
-
That is why I asked what people would want in an xref suite. To help out the community. Also to learn.
Is that another thread somewhere??? I have suggestions :)
-
Okay a suggestion, maybe this is too soon for this level of detail but....... We frequently incorporate vendor drawing information in design drawings, can the function be so designed to pull layer information from a separate template file or a standards file, then if that layer doesn't exist, create it and set parameters, if it does exist giove the option for using current settings or replace with template/standards settings?
I wrote a tool--for my company--wich does all that; The simple "move-to-layer" jumped from about 50 lines of code to almost 500 but its definatly do-able if we get enough help.
-
That is why I asked what people would want in an xref suite. To help out the community. Also to learn.
Is that another thread somewhere??? I have suggestions :)
http://www.theswamp.org/index.php?topic=37582.0
Suggest away.
-
for sure!
:-D
It's a language way above your abilities LE.
:-P
-
If "Boss" isn't intended to be singular (or E Street :-P ), I can be on board for scheduling, QA/QC, and other admin whatnots. Maybe some documentation as well. Would be nice to earn that hereditary title of "Master of Assassins" back...
-
If "Boss" isn't intended to be singular (or E Street :-P ), I can be on board for scheduling, QA/QC, and other admin whatnots. Maybe some documentation as well. Would be nice to earn that hereditary title of "Master of Assassins" back...
We can have a sign up or vote or whatever. I will put 110% into what ever postion i am offered. Should we start the sign up?
-
If "Boss" isn't intended to be singular (or E Street :-P ), I can be on board for scheduling, QA/QC, and other admin whatnots. Maybe some documentation as well. Would be nice to earn that hereditary title of "Master of Assassins" back...
We can have a sign up or vote or whatever. I will put 110% into what ever postion i am offered. Should we start the sign up?
No problems here. I think the "admin staffing" should be handled first, since providing scope and preferred coding langauge will in part determine who will want to contribute what. After that
-
Did I miss something?
LAYMCH
Quick Reference
See Also
o Use Layers to Manage Complexity
Changes the layer of a selected object to match the destination layer.
Access Methods
Button
Ribbon: Home tabLayers panelMatchNot available on the ribbon in the current workspace.
Menu: FormatLayer ToolsLayer MatchNot available in menus in the current workspace.
Toolbar: Layers II
Summary
If you enter -laymch at the Command prompt, options are displayed.
List of Prompts
The following prompts are displayed.
Select objects to be changed: Select an object to change its layer
Select object on destination layer or [ Name]: Select an object or enter n to open the Change to Layer dialog box
Select Object on Destination Layer
Select an object on the destination layer.
Name
Displays the Change to Layer dialog box.
If you create an object on the wrong layer, you can change its layer to the one you want using LAYMCH.
Topics in this section
* Change to Layer Dialog Box
Displays a list of layers to choose as the destination layer. You can also create a new destination layer.
* -LAYMCH
-
Did I miss something?
Maybe this part?
2. I realize this project can be done by one person but the act of working in a group is my overall objective (It will not only strengthen member ties but allow others to learn).
-
A contribution:
(defun ChangeEntityLayer ( entity layer )
( (lambda ( entitylist ) (entmod (subst (cons 8 layer) (assoc 8 entitylist) entitylist)))
(entget entity)
)
)
[color=green]Purpose:[/color]
Function will set the layer of the supplied entity to the specified layer.
[color=green]Arguments:[/color]
entity - [ENAME] Entity name of entity to process
layer - [STRING] Name of layer, will be created if non-existent
[color=green]Returns:[/color]
Updated DXF Data list if successful, else nil.
A handy wrapper function demonstrating usage:
(defun c:test ( / ss la i )
(if
(and
(setq ss (ssget "_:L"))
(setq la (getstring t "\nSpecify Layer for Selected Objects: "))
)
(repeat (setq i (sslength ss))
([color=red]ChangeEntityLayer [/color](ssname ss (setq i (1- i))) la)
)
)
(princ)
)
-
Please note: I am trying to ballance honestly with politness with the following post (grain of salt -> you). ...why i feel the need to prefix a post and or be diplomatic in responce in a acidemic enviorment is another thing.
hermanm, thank you but this is a group project to create something (anything). In that, each person takes a task and builds something. If you feel this isnt a good project (I would appreciate your thoughts) please recommend another (I took a shot in the dark at something I felt would offer the most opportunities for people of all levels of experience to contribute to).
Lee, thank you for your `contribution' but let me try to be as nice as I can and try to explain what/how that was "not" what this thread wanted at this time (For the record: I am assuming that *I* did a poor job explaining myself and *you* were only trying to help--if this isnt the case let me know so that I can adjust my score card accordingly-).
The word `contribution' means "gift". -i.e. was/is it your only intension to `contribute' this piece or would you like to sign up to be a member of the team? I am not saying that I dont appreciate your `contribution' or the quality of it but I cant promise that it will get used because I dont know who and what their influences are/will be for making that particular piece.
Now, please let me try and better explain my intentions to try and eliminate all confusion.
I wanted to start a group project (several members talking/sharing ideas/working together) to assemble a final product (each person takes a task and contributes). Years ago Mark or I (I dont remember who originally came up with the idea) wanted to ask one of the BSD developers to run a group project here on theSwamp but it never happened.
This may be too small of a project to try and assemble a team on but I am not exactly sure why I am having problems assembling a group of people to work on a project together (I have tried to eliminate "time", "difficulty" and "lack of tools" so-far). Are there any other factors I need to eliminate to get a group of people to work on a project together (what am I missing)? I feel I am being totally honest and upfront with my questions and desire for help but I feel like I am being ignored and I am about ready to give up.
I put a LOT of work into the LispFileProcessor tool because (besides the fact that I felt that we lacked a good tool; logistically speaking) I honestly feel that the group project experience could lead to several other--larger--group projects and set this site and its members apart from all the others (I dont feel that there should be any question in anyones mind that theSwamp is the best place on the internet for AutoCAD help--I want to bury the other sites-).
A group effort will allow people to learn about or refine knowledge about other methods, tools, thought process', etc. For example: Allow people to use and learn how to use a SVN server (theSwamp) and give people in-site into what other people consider reliable or useful code or tools.
Should I quit? Was my time wasted?
I dont know how else to explain myself/my thoughts. If anyone else can do a better job, please do so.
-
Per my experience...
- Tried something similar many moons ago - not here at the swamp, end up me doing almost everything.
- Tried to have a group to write apps, opened a web site, wrote all the based, then me was the only one doing all.
- Many times have posted some routines, and got no replies et al - today I see that as normal, and do not get it as a personal.
- All of the above moved me into simple upload basically all of my own stuff (that can be shared) as open source, that way if someone find it useful, they can use it, and there is no connection, and that's it.
- Nowadays, if I can share or help, I simple do it, and that's all.
My 2 pesos worth, if any :)
-
LE, I dont like it but I understand what you are saying. However, if you ever wanted to start a group project again, you can count me in.
-
I think I get it (think so anyway) and I like it. As a coding neophye wanting to learn I also like the idea of a smaller, simpler project exactly like the one outlined here. Working together (regardless of task or even result) we will accomplish several things, among them ; building working relationships that will be useful later on major projects, learning interesting techniques employed by other coders, discovering unique specific talents of specific contributers, and not the least of which would be teaching a goober like me PROPER coding techniques, plus a bunch of other "community/code" building benefits.
(If I'm close se7en nod, if not slap me and make me walk home nekkid').
-
*Se7en: nods*
-
sweet, I'm close ... and I ain't walkin' .... today's a good day all around.
Okay, sign me up. I'm no coder, but I can break stuff, and I have an eye for a turned phrase. So, if you'll have me, I can help with beta testing and the documentation side writing/editting.
-
Here are the steps as I see them (please add to them if you see the need):
1. Establish concice criteria.
2. Have member signup
3. Chose roles / Member election
(
soldiers divide code into tasks [ list functions to be created],
Assassins decide on documentaion format [txt, doc] for soldiers,
Lieutenant decides on package format [zip, exe, installer] and
decides how soldiers code will be assembled
[from peices, from files, from posts],
Boss assigns soldier tasks, and helps facilitate extra tools
[if lieutenant decides a SVN is to be used (s)he
would ask Mark to set up SVN access]
)
4. Work.
We are in step #1.
-
Seven, I'll get one of the balls rolling here. Just had a brain dump while re-installing AutoCAD on a borked laptop. Like you mentioned, its a bit early to be getting into the code. Personally, *not* starting with code was one of the hardest habits to break.
The final product will be two products capable of being loaded "blind" into an existing AutoCAD system without interfering with other customization. The "release" version will be a single, self-contained compiled FAS file. The "dev" version will contain a small number (~4-5) of raw LISP files.
A few general guidelines:
- The project will be coded in LISP, to keep management simple.
- Both Visual LISP and DXF/(entmake...) functions will be acceptable. I'm hoping to get a SubVersion of this going with separate branches for each.
- All functions and global-scope variables will be prefixed by "7WIP:" e.g. 7WIP:functionName, 7WIP:variable_name. This will avoid ambiguity and interference with other projects.
- Use of globally scoped variables will be minimized
- Function and variable names will be verbose e.g. 7WIP:functionName not 7WIP:fNm; layer_list not llst.
- Each function will be preceded with comments describing the type and expected input for each argument, and the type and expected return value. A brief outline of what the function does will also be included.
- For now, each function will have its own file to assist with management. Once things get spun up the files will be combined and we will use the Swamps SubVersion repository for diff'ing checked out code.
Division of code:
- Error module: error handler, system variable stack handlers
- User interface module: dialogs
- Core module: actual work goes here
- Support module: common support functions called from multiple locations, global variables
-
Lee, thank you for your `contribution' but let me try to be as nice as I can and try to explain what/how that was "not" what this thread wanted at this time (For the record: I am assuming that *I* did a poor job explaining myself and *you* were only trying to help--if this isnt the case let me know so that I can adjust my score card accordingly-).
Ok, maybe I jumped in a bit quick with the code - I saw you were getting agitated by the lack of interest, so I jumped in to get the coding ball rolling and perhaps generate some more interest when members see something getting started.
The word `contribution' means "gift". -i.e. was/is it your only intension to `contribute' this piece or would you like to sign up to be a member of the team?
I think the 'sign-up' aspect is what may be detering some members from threads of this nature - note that most come here to browse and come and go as they please as a release and form of relaxation from work, and hence don't want to be tied down to another project outside of work as well, where there may be some expectation for them to contribute something to the project. Furthermore, I don't think too many will be overkeen on the 'rank' system - I realise there needs to be structure and that tasks may be delegated to different users, but I would remove the word 'boss' if you catch my drift.
Overall I understand your intention - to inspire the community to work together to everyones strengths, so that members can learn from the coding (and perhaps organisational) strengths of others and vice versa; and I completely agree that it would be a good idea. But, (and maybe I'm wrong here), I should imagine many may view this as 'work' and won't want to get involved on top of a hectic day job - of course, as I've demonstrated, I'm personally happy to contribute to the project.
As always, take my thoughts as a pinch of salt and don't read too much into my thoughts of the community as a whole, I'm likely way off.
Lee
-
point taken but what should we call him/her? the 'boss' shall now be known as...wait for it..."the great pumpkin". *smile*
my stance; we are technical minded, not hippies, a boss is someone in charge.
let's stick with 'boss' until it gets brought up again (becomes an issue) and then we can adress it then but let me think about the 'extra work' issue you brought up a bit.
-
I'm amenable to "Mr. Springsteen" instead of "Boss" if you are looking for ideas. :-D
I have a couple of ideas to handle the "ugh, more work..." issue. The first is a job jar, where various small tasks are posted. Anybody who has an hour or two can sign one out, do what they can, and sign it back in. If they get overwhelmed then it can just be returned as unmodified for somebody else to get started. The other is maintaining a much more relaxed schedule (IMHO we do still need one) to give people a chance to do this as well as the paid work. So what would normally be assigned for a week in a paid job would be several weeks or even a month. Even now, I think a couple of weeks are needed to get people signed up.
-
B.O.S.S. = Big Ol' Silly Shi ...... ummm ..... Stuff
-
I like the job jar idea but I also want to say that I, personally, dont have any formal or professional group experience (hence the reason for all this) so i am just offering my best guess on all this stuff so im sure we are gonna fail with some methods or tasks we choose. ...I wonder if we shouldn't just call the criteria good enough and start the sign up process to see what "level of experience" we get (work with what we got). Thoughts?
I can assemble what criteria was listed so far in a text file for our use.
BTW, just to list some pertinent (development/technical) background info on me:
I am using Linux (I will be doing most of my work at home on my laptop but i use Windows at work too so...).
I have a live.com account (so i can chat with that messenger thing).
I would be willing to talk on the phone.
I use the Vim text editor.
I can program in: C++ (and Qt) and both Auto/Visual Lisp.
I am comfortable with the Unix-Style development process (text editor -> makefile -> compiler -> final product).
I am comfortable with the IDE style development process.
-
Here is the latest document (from the first post) with all the criteria listed so far.
-
Good brief.
A few things I might be inclined to add:
- Remove use of underscores in variable names, these are irritating to type and look ugly
- Consider whether to write a temporary Dialog Definition file (DCL) and [optionally] delete such file following main procedure, or include the DCL as a separate file in the package
- Include an 'new layer' button in the Dialog? - (but then would this require another dialog, and how far to take it regarding layer properties...)
- Remember to exclude XRef layers from Dialog layer list
- Exclude Objects on locked layers from object selection
- Consider order of prompts, i.e. Object Selection -> Layer Dialog (my preference) vs. Layer Dialog -> Object Selection.
Just brainstorming a few thoughts for this task. How shall we proceed from here?
Lee
-
> no underscores
sure. I dont care one way or the other; i want a standard.
> temp or DCL file.
Temp.
>new layer button
I vote no.
> xref layers and locked layer items
of course.
> order of prompts
first one.
I would say that we need a sign up sheet to see what kind of talent base we get.
-
agreed x6
-
Sounds like a lot of fun and the group base work could be really beneficial to a lot of people - including myself. Count me in for anything.
-
Here is the latest criteria document.
Can someone create a list of members or create a new thread for signup (somehow keep track of the members we have).
Another item We/I need to address is the SVN issue. TortoiseSVN is can be used as the interface, as well as batch scripts so we need to do some reading up on SVN and make some decisions. We also need to get Mark involved now and either get access/user account/etc setup or opned to us...
Mark, if your reading this, get your a55 in this thread and make some noise.
The last item to be addressed is comunication. Im not sure a thread will work; should we create a new forum (a group under the AutoLISP forum or something)? Should we get an IRC or chat channel. At least one "meeting" -e.g. "project kick off" would be nice.
-
Just thought of one more thing for the brief:
- Should the Dialog 'remember' the last selected option? [My Preference: Yes]
If Yes, store Layer Name [to be checked each time for existence of layer, else first item in LayerList is used] as:
- Global Variable in active drawing namespace [My Preference since in most cases, layers differ between drawings]
- Blackboard Variable in Blackboard namespace
- Registry key
- In text file
Your thoughts?
-
I am on the fence about that one Lee but if "yes" i vote txt file (so it would be avail after a restart).
...to add to the `yes options' (this thought just came to me): what about if we re-write the program file (append a function to it something like: "(defun globalvar ( / ) "my-last-layer")" or something like that). Of course we would have to build some error proofing on that but you get the idea.
-
I am on the fence about that one Lee but if "yes" i vote txt file (so it would be avail after a restart).
I was just considering that the layer setup may be quite different from file to file, so a simple global would be the least intrusive (and easiest to code), whilst still aiding the user.
...to add to the `yes options' (this thought just came to me): what about if we re-write the program file (append a function to it something like: "(defun globalvar ( / ) "my-last-layer")" or something like that). Of course we would have to build some error proofing on that but you get the idea.
That could be another option, yes - I suppose one would have to weigh the coding needed to read/write the lsp file coupled with testing for existence of the globalvar function against a single read/write to another (separate) text file but with the baggage of an extra file (albeit small).
Another option could be to define a subfunction as a list, i.e.:
(defun-q MySub ( / x )
(setq x 1)
(setq x (cond ( (getint (strcat "\nEnter a Number <" (itoa x) "> : ")) ) ( x )))
(setq MySub (cons (car MySub) (cons (list 'setq 'x x) (cddr MySub))))
(princ)
)
This would behave in the same way as the use of a Global Variable, but removes the need for a Global Variable floating around.
Lee
-
i vote txt file (so it would be avail after a restart)
the layer setup may be quite different from file to file,
Why not an Xrecord in a Dictionary ?
-
i vote txt file (so it would be avail after a restart)
the layer setup may be quite different from file to file,
Why not an Xrecord in a Dictionary ?
My preference. Establish a dictionary under the named object dictionary, with a sub-dictionary for settings like last-selected layer, last dialog selection, etc. Safe, doesn't require extenstive permissions like registry keys might, doesn't rely on search paths and their possible write permissions like a text file, and stored per drawing.
-
i vote txt file (so it would be avail after a restart)
the layer setup may be quite different from file to file,
Why not an Xrecord in a Dictionary ?
My preference. Establish a dictionary under the named object dictionary, with a sub-dictionary for settings like last-selected layer, last dialog selection, etc. Safe, doesn't require extenstive permissions like registry keys might, doesn't rely on search paths and their possible write permissions like a text file, and stored per drawing.
Really? I'm surprised - I wouldn't have thought one would want all this extra baggage to bloat a drawing just for the sake of remembering a dialog selection. Hence why I thought a simple global variable would suffice.
-
i vote txt file (so it would be avail after a restart)
the layer setup may be quite different from file to file,
Why not an Xrecord in a Dictionary ?
My preference. Establish a dictionary under the named object dictionary, with a sub-dictionary for settings like last-selected layer, last dialog selection, etc. Safe, doesn't require extenstive permissions like registry keys might, doesn't rely on search paths and their possible write permissions like a text file, and stored per drawing.
Really? I'm surprised - I wouldn't have thought one would want all this extra baggage to bloat a drawing just for the sake of remembering a dialog selection. Hence why I thought a simple global variable would suffice.
I have to agree with Lee. I can't imagine where the last selected layer would be good past the active drawing's current run.
-
I just tried to reply to the 2 requests:
- [se7en] keep the value after closing the drawing (a global variable won't)
- [Lee] have a value per drawing (a .txt file could but it needs something like a line per drawing/value)
What's wrong with the dictionary ?
It could be a 'ldata' too if the application only uses LISP.
-
good idea gile but I dont really mind any solution. The main reason I am still on the fence is because I'm still wondering if its a "usefull feature" (If its a usefull feature for people im cool with either concept).
When the dialog pops up the last layer will be highlighted?
The long and the short is, if you guys think its a usefull feature im on board with it. If we have to choose a solution i think gile hit on a good idea (but yes, a global var would be easier and less code). bleh, i'm just muddling this decision. Decide and we'll add it to the criteria.
-
Not being a coder lemme throw in here.
#1) It may be useful to some and not others, the kind of stuff I do most often is unique enough I probably won't need it that often, but that's ME.
#2) As a group for this effort, (remembering that the effort is as much or more about working as a group than it is about the end product), do we as a group want to code more or code less for our first attempt at a group project? Leaving the endproduct aside for a minute we might consider that less may be more for our first foray, but more may be beneficial for the group health. Dunno, just saying.
-
i vote txt file (so it would be avail after a restart)
the layer setup may be quite different from file to file,
Why not an Xrecord in a Dictionary ?
My preference. Establish a dictionary under the named object dictionary, with a sub-dictionary for settings like last-selected layer, last dialog selection, etc. Safe, doesn't require extenstive permissions like registry keys might, doesn't rely on search paths and their possible write permissions like a text file, and stored per drawing.
Really? I'm surprised - I wouldn't have thought one would want all this extra baggage to bloat a drawing just for the sake of remembering a dialog selection. Hence why I thought a simple global variable would suffice.
You'll have to trust me - VERY little bloat involved with this method. At least on the storage side. It does require more code than a global variable, and only slightly more than for reading/writing a text file once you validate the input/output.
As also mentioned, the simplicity of a global variable might be best for the design stage. Wrapping the global variable with a set/return function will enable the method to be easily replaced in a code branch later on.
-
The way I see it:
- Whether it will be useful for the user or not, the dialog list_box requires an initial selection, hence it might as well be the previously selected layer from the dialog.
- The goal of this program is to aid drafting and shouldn't affect the drawing itself, so the setting shouldn't be tied to the drawing - this point is even more valid considering that a percentage of users may not even require the setting to be remembered and many are probably not overkeen on such an app altering their drawings just to set an object's layer.
- As a global variable, the drawing (and system) is unaffected either way, so a user on both sides of the fence is happy.
-
The way I see it:
- Whether it will be useful for the user or not, the dialog list_box requires an initial selection, hence it might as well be the previously selected layer from the dialog.
- The goal of this program is to aid drafting and shouldn't affect the drawing itself, so the setting shouldn't be tied to the drawing - this point is even more valid considering that a percentage of users may not even require the setting to be remembered and many are probably not overkeen on such an app altering their drawings just to set an object's layer.
- As a global variable, the drawing (and system) is unaffected either way, so a user on both sides of the fence is happy.
While I agree that using ldata/xdata wouldn't clog up the system, I still have to agree with Lee on this. A global variable is the least intrusive and for what it's accomplishing, it more that sufficient.
I have to know, what's the aversion to using a simple global variable?
-
I have to know, what's the aversion to using a simple global variable?
I've no aversion to use one or another way, I just wanted to say the choose of a route must be dictated by goal.
Maybe, one more time, I misunderstood the request (due to my poor English) and it's the main reason I won't join this group.
I thaught the data had to be preserved after the drawing was closed, so a global variable won't be a good choice.
So to resume, before discussing which way is the best, have to decide where to go.
-
Applications modify drawings all the time without users having a clue as to whats being done.
A variable for this, a variable for that... they get out of hand easily and I'd prefer to avoid a precedent. They are also easy to modify in an uncontrolled fashion which can cause problems in collaborative efforts. Maybe its just the methodology I've adopted. I *do* use a few global variables for things like application names, but for the most part use functions to return values instead. Then if the method of getting the value (hard-coded vs. registry, for example), it only needs to be changed in one place rather than find/replacing every reference.
-
I thaught the data had to be preserved after the drawing was closed, so a global variable won't be a good choice.
Ahh, OK. I'll keep my mouth shut.
-
Applications modify drawings all the time without users having a clue as to whats being done.
That may be, but why are you encouraging that practice?
A variable for this, a variable for that... they get out of hand easily and I'd prefer to avoid a precedent.
1 Variable: the Layer Name.
Seriously, this seems like arguing a moot point for the sake of it.
-
Seriously, this seems like arguing a moot point for the sake of it.
Whatever, I totally disagree. :evil:
-
Seriously, this seems like arguing a moot point for the sake of it.
Whatever, I totally disagree. :evil:
(http://i419.photobucket.com/albums/pp280/NewsChat/Smilies/stirrer.gif)
-
Applications modify drawings all the time without users having a clue as to whats being done.
That may be, but why are you encouraging that practice?
A variable for this, a variable for that... they get out of hand easily and I'd prefer to avoid a precedent.
1 Variable: the Layer Name.
Seriously, this seems like arguing a moot point for the sake of it.
Sorry - not intending to argue.
Can we agree to put a pin in it until later? I think we still need to mock up the UI and decide what (if any) of the settings will be saved, and the save scope, before looking at how that data would be saved.
-
I know the option to create a layer if it doesn't exist was negated, so I'm sure this will be too, but I'm going to say it anyway: What about an option to view the list of available layers in the drawing - sans XRef - and another option to view layers (that can be imported with ODBX) from a specified drawing (default being the defined template file)?
I definitely think the dialog should have a text box, so the user can type part of the layer and the list is filtered down to display only layers matching what's been typed so far.
-
Can we agree to put a pin in it until later? I think we still need to mock up the UI and decide what (if any) of the settings will be saved, and the save scope, before looking at how that data would be saved.
Agreed. :-)
As for the UI, here's a quick mock up of what I thought Se7en had in mind (as a basic 'first draft'):
(http://www.theswamp.org/screens/leemac/UImockup.png)
Boss (Se7en?): Let me know if I'm going too far ahead or overstepping my 'duties' and I'll put the brakes on.
-
perfect.
Well within range; we need to have good concepts and criteria before we get too far. Keep going.
-
I know the option to create a layer if it doesn't exist was negated, so I'm sure this will be too, but I'm going to say it anyway: What about an option to view the list of available layers in the drawing - sans XRef - and another option to view layers (that can be imported with ODBX) from a specified drawing (default being the defined template file)?
Nice idea! - I could envisage representing this in the dialog perhaps as text above the list_box reading 'Select Layer From' with a popup_list listing the current drawing, the template file and a 'Browse...' option allowing the user to browse for an arbitrary file - then, the layers could be listed for the option selected.
I definitely think the dialog should have a text box, so the user can type part of the layer and the list is filtered down to display only layers matching what's been typed so far.
Another great idea - I agree.
-
First, let me just say "Thank you" to everybody. Is it just me or do you guys think this is kind of fun?
Secondly, technically speaking theSwamp was added to my company's firewall "black list" (I had to do some "magic" to just be able to view theSwamp) a couple of weeks ago so my participation is limited to at home and at lunch when the firewall black list is turned off.
As most of you can see this project doesn't really have a deadline but i think we may need to add a one for our own sanity. There is nothing saying that we cant use this tool or the knowledge from it as a basis for a future group project so i want to recommend that we put a time limit on the criteria list and let the real fun (like meetings, documentation, development, testing, packaging, etc.) However, I think you guys are making some real good suggestions and progress so i also dont want to hinder that process. How would you guys feel about making a deadline on the addition of criteria? Something like: next Wednesday.
Thanx again.
-
I know the option to create a layer if it doesn't exist was negated, so I'm sure this will be too, but I'm going to say it anyway: What about an option to view the list of available layers in the drawing - sans XRef - and another option to view layers (that can be imported with ODBX) from a specified drawing (default being the defined template file)?
Nice idea! - I could envisage representing this in the dialog perhaps as text above the list_box reading 'Select Layer From' with a popup_list listing the current drawing, the template file and a 'Browse...' option allowing the user to browse for an arbitrary file - then, the layers could be listed for the option selected.
<snip>
[grain of salt]: One of my reasons for not wanting to offer a DBX-Template file feature (my comment about the 50 lines grows to 500) was because i didn't want to use a "settings file" (or an INI file so to speak). My thought was that maybe not office uses the default template for new files as a repository for layers and other standards (my office doesn't). [/grain of salt]
I like that filter idea. I cant think of...you guys have some ideas? I think that would be really cool.
-
First, let me just say "Thank you" to everybody. Is it just me or do you guys think this is kind of fun?
Definitely - its great to work together on something :-)
How would you guys feel about making a deadline on the addition of criteria? Something like: next Wednesday.
Fine for me.
I know the option to create a layer if it doesn't exist was negated, so I'm sure this will be too, but I'm going to say it anyway: What about an option to view the list of available layers in the drawing - sans XRef - and another option to view layers (that can be imported with ODBX) from a specified drawing (default being the defined template file)?
Nice idea! - I could envisage representing this in the dialog perhaps as text above the list_box reading 'Select Layer From' with a popup_list listing the current drawing, the template file and a 'Browse...' option allowing the user to browse for an arbitrary file - then, the layers could be listed for the option selected.
<snip>
[grain of salt]: One of my reasons for not wanting to offer a DBX-Template file feature (my comment about the 50 lines grows to 500) was because i didn't want to use a "settings file" (or an INI file so to speak). My thought was that maybe not office uses the default template for new files as a repository for layers and other standards (my office doesn't). [/grain of salt]
That's reasonable - lets keep it simple for now.
I like that filter idea. I cant think of...you guys have some ideas? I think that would be really cool.
Another quick mock-up with the Filter idea, (was thinking just a wild card filtering system):
(http://www.theswamp.org/screens/leemac/UImockup2.png)
With regards to code, I'm good to go on any part of the project, but of course, although this could be completed by one person, I understand the overall goal is to get as many members involved as possible so I would only focus on a particular sub (like dialog handling for example - I enjoy coding that :wink: ).
My only reservation is in the case where a number of members have all coded the same part of the project - who is to decide which code is to be used? There are many ways to accomplish the same thing in LISP...
-
yeah, thats why we need to elect a Boss (so (s)he can divide and delegate). ...this isnt a power trip or anything but since no one has elected to do it and i'm starting to see that the boss kinda needs some coding experience should i just toss my name in the hat for Boss?
-
Another quick mock-up with the Filter idea, (was thinking just a wild card filtering system):
(http://www.theswamp.org/screens/leemac/UImockup2.png)
Should also give the option that if the full layer name is typed into the filter box, the objects are placed on that layer - make things quicker.
-
This may sound crazy, but what about compiling this and any other tools we write together and offering an exclusive donate any amount to download from theSwamp? All proceeds going straight to Mark, of course.
-
A wonderful idea alanjt! I vote that all current criteria discussions be halted until a majority vote on that suggestion is reached.
*thought* We can have:
1. a private forum.
2. open discussions but private SVN access where all code and docs are posted to.
I can see benefits and problems for both but i vote we close this project (when we start discussing the actual details) to non project members (create a private forum) immediately.
-
Hi Everyone
I can't wait when you start work on something :)
How about multi-language support (for prompts and DCL) ?
kruuger
-
How about multi-language support (for prompts and DCL) ?
Nice idea - you might have to do the translation though :wink:
-
How about multi-language support (for prompts and DCL) ?
Nice idea - you might have to do the translation though :wink:
Yees, especially chinese, japan ... ;-)
k.
-
How about multi-language support (for prompts and DCL) ?
Nice idea - you might have to do the translation though :wink:
I volunteer to translate English English to American English and remove all those crazy U's. :lmao:
-
The last "group project" I worked on used a wiki to allot tasks, highlight deadlines etc.. it was the first place anyone in our group went before posting a query on the group forum. Would this project use something similar?
-
I volunteer to translate English English to American English and remove all those crazy U's. :lmao:
[/quote]
Funnily enough I was going to offer to do the opposite translation to put in all those missing Us lol
Regarding the filtering system, would it be possible to do an "implied" *filter* (so that for example "wall" would automatically be interpreted as *wall*)?
I second Se7en's "boss" candidacy (I'd kind of assumed he'd be the "boss' boss" anyway <shrug>
Given that this is to form part of a larger library, would our best option perhaps be to establish a "library saved variables" procedure and tap into that for this project?
dJE
-
The last "group project" I worked on used a wiki to allot tasks, highlight deadlines etc.. it was the first place anyone in our group went before posting a query on the group forum. Would this project use something similar?
Do you have something in mind jane doe? Do you have an example or link you can toss us?
I would like to keep it on theSwamp but im sure i can talk Mark into giving us a small amount of server space if we need a website however, would the private forum (a sub forum inside here where only project members can access) idea be good enough?
-
The last "group project" I worked on used a wiki to allot tasks, highlight deadlines etc.. it was the first place anyone in our group went before posting a query on the group forum. Would this project use something similar?
Do you have something in mind jane doe? Do you have an example or link you can toss us?
I would like to keep it on theSwamp but im sure i can talk Mark into giving us a small amount of server space if we need a website however, would the private forum (a sub forum inside here where only project members can access) idea be good enough?
If not, we could always just use a Google group, but I'd much rather keep everything at theSwamp.
-
The last "group project" I worked on used a wiki to allot tasks, highlight deadlines etc.. it was the first place anyone in our group went before posting a query on the group forum. Would this project use something similar?
Do you have something in mind jane doe? Do you have an example or link you can toss us?
I would like to keep it on theSwamp but im sure i can talk Mark into giving us a small amount of server space if we need a website however, would the private forum (a sub forum inside here where only project members can access) idea be good enough?
The wiki was hosted on the university server, so I would assume it could be hosted here (with Marks blessing) The wiki complemented forum posts, as the wiki was used for information, and posting the results of discussions we were having on the forum board, highlighting deadlines and general project management.
I'll look through my notes this evening to see if I can see which wiki was used.
-
Update on the SVN here at the Swamp (thanks again, Mark!), I'm setting up a trial repository now. I'll post more results in a couple of days, including proposed procedures for code control.
-
^ that's huge! thanx dgorsman.
-
Project Announcements:
1. Next Wednesday (04.13.2011) is the final day to submit and decide upon criteria.
2. Please vote on if you would like this project to be donated to Mark (theSwamp) to use as a bonus for donations.
a. Please vote on if you think closing this project off from the general public or using private SVN access for this reason.
-
2. Please vote on if you would like this project to be donated to Mark (theSwamp) to use as a bonus for donations.
a. Please vote on if you think closing this project off from the general public or using private SVN access for this reason.
I don't think it's robust enough for that: too many similar free programs floating around. Don't get me wrong: I like the idea, but, maybe use this project to get the group thing down and then tackle something more difficult. My vote would be to create a utility that uses a .dwg as a database . . . just sayin.
-
Drawing as a database for what (layers to import)?
-
Project Announcements:
1. Next Wednesday (04.13.2011) is the final day to submit and decide upon criteria.
2. Please vote on if you would like this project to be donated to Mark (theSwamp) to use as a bonus for donations.
a. Please vote on if you think closing this project off from the general public or using private SVN access for this reason.
I dont have a problem with donating it to Mark to use for additional donations. but I also agree with jbuzbee.
Drawing for a list of layers would be nice, that way, anyone who uses the project wont have to be a coder to input their custom layer names in some lisp routine. We'd just have to provide in the documentation instructions on how to name your drawing, and where to put it.
-
I've got nothing against donating this project to Mark, but I thought this was an open source project so that members could learn from the code?
-
Drawing as a database for what (layers to import)?
I'm always questioning why someone would want to use an outside database (sqlite, excel) when a .dwg file IS AutoCAD's default database. And, AutoCAD gives us a way to access said database with ObjectDBX. What would be nice is to have tools to make managing a "drawing" database easier: xdata to sort and categorize complicated objects, i.e. blocks, styles, vertical objects, etc. Dictionary tools for storing non-graphical data: project info, office standards, ways & means, etc.
I use a drawing as a database now: layers, layer states, blocks, styles, etc. but I can only categorize objects by using tricky names: tag_roomName is my roomname block. Better to have xdata categorizing the block as a tag. Make sense?
-
This project is--and can remain so--most certainly open and for learning but I would also be a fool for not considering all options (That's what I wanted the members to vote; its our project). I'm glad you guys are voting. Please speak up when you feel the need.
> Drawing database / drawing layer issue.
The drawing database for layers *can* be done but the question remains is it a popular or useful feature for most people; I dont want to limit the use of it based upon the tools requirements. Code is easy, we can create other variations or plug-ins to it. -e.g. I don't use a drawing standard layers for my company because of the all the departments I have (It would be far too many layers in our drawings if I were to include all of them). So, I feel we need to address the issue of creating either an INI (settings file) or a choose drawing to pull from. All I am saying is If we can limit the specificity of the tool, we can have a larger user base.
So, to get the `drawing layers isuse' ball rolling; I recomend that we create a setting dialog box and a INI file. The setting dialog will be run if the INI is either empty or missing. The INI file should be able to be deleted or reset via the main dialog. If the INI is reset should we open the settings dialog or have a simple label with an elipsis button in the main dialog?
BTW jbuzbee, are you participating? You havent answered my question in the SIGN UP thread.
-
Why dont we just code for both, if the drawing doesnt exist, use the ini file, if neither exists, post an error or alert message?
-
Project Announcements:
1. Next Wednesday (04.13.2011) is the final day to submit and decide upon criteria.
2. Please vote on if you would like this project to be donated to Mark (theSwamp) to use as a bonus for donations.
a. Please vote on if you think closing this project off from the general public or using private SVN access for this reason.
2.) Most definitely. "Open Source" does not prohibit appreciative support and should encourage such.
2a.) abstain - I see pros and cons both ways. To my little mind, the focus of the project is more about the 'group" effort than the product, so rock-throwing from the peanut gallery may be distracting from that aspect of the effort. On the other hand, we all know that a simple comment from someone outside the current battle might be just the thing that moves a stuck project out of the mud.
-
There has been smart people stuff words used so I might not fully understand so forgive me if I am off subject.
I would love to contribute but when it comes to Lisp my lack of knowledge would be a burden.
So I do not know how Lisp performance would be but I will throw this out there if it will spawn any ideas.
Created a .NET app that used dwg's as layer files.
Instead adding all the layers to dwg it listed the layers from the dwg by discipline selected.
It would only bring in the layer if needed instead of adding a bunch layers.
What ever layer selected all objects would drawn on that layer and it would add from layer drawing if current database did not have layer.
If objects were already selected and you double clicked on layer name it put all selected objects on that layer.
Do not know if you would want this functionality but it would separate layers by New, Existing, Demo
You could select a color for Demo and Existing.
For example if you had Existing selected it would create a new layer with the color specified for Existing and add a -E at the end... -D for Demo,
so if you wanted to view in 'New Phase' all Demo layers would be off.
So the only time you would create a Existing layer in the layer file is if you wanted it to have a different linetype.
Would change layers from Existing to Demo to New etc.......
Kinda like Renovation tool
Would create seperate drawings and or layouts for new and existing.
I shut-up about that now since you get the idea
So maybe to contribute something from .NET side I have thought could be useful for Lisp user's and Kerry or Gile would know for sure if it would be to much of a hassle, but
to make creating palette's, forms, ribbon's a simple task in AutoLisp.
I do not see why not if someone wanted to take the time they create a separate program that you could create UI visually by dragging and dropping and create code to add to .lsp or call from UI library.
In the pic below from app described above it would not be hard to tell what names to use for layer file or how to group etc..... could return layer name or ObjectId(whatever you need in Lisp).
Of course as just explained it would not be a very reusable, but I would think a Library UI could be abstracted to point of being useful.
Sorry if I just wasted 5 minutes of your life.
-
<snip>
One of the reasons I proposed this be done is LISP is the relative simplicity of not only coding, but management. I'm not sure about the collective experience level in using SVN to collaborate on a project and while there isn't a direct plug-in for the VLISP IDE, we don't have to fight both the language and collaboration.
That said, I am considering a .NET branch of the SVN once we get going.
-
After consideration, I'm voting for free access, for the first part. Yes, we could donate it for use afterwards but the start-up nature of the project will likely make it more of a "meh" than a "Yeah!". If this leads to more then I think we should give serious consideration to either providing the contents as a thank-you for donations, or provide previously release versions in FAS format as a free teaser and the source code as the thank-you.
-
After consideration, I'm voting for free access, for the first part. Yes, we could donate it for use afterwards but the start-up nature of the project will likely make it more of a "meh" than a "Yeah!". If this leads to more then I think we should give serious consideration to either providing the contents as a thank-you for donations, or provide previously release versions in FAS format as a free teaser and the source code as the thank-you.
I'm good with that too. The download by donation was just a thought to bring a little money Mark's way.
-
I know this is a last minute feature suggestion, but how about adding an "and make new layer current" button.
dJE
-
A few notes on the Subversion SVN for those that are not familiar with it.
One of the problems with collaboration (especially over the internet) is how do you manage contributions from multiple people? This becomes a real problem with code files where multiple functions reside, such as LISP files. This is where Subversion comes in to play: allowing users to make contributions in the same file without (necessarily) overwriting the work of others or locking others out for the sake of a minor change.
A central repository is created in a common location (in this case, here at theSwamp), with folders and files as required. Each user installs a Subversion client application (TortiseSVN is recommended) which manages the users connection to the repository. A local "working copy" folder is connected to the repository using the application, which will download/upload the selected files and folders. Now, for the cool part. When the files in the repository are changed the SVN client can be used to indicate *what* was changed from the users working copy, and those changes can be incorporated into the users working copy without disturbing any changes the user has made (provided it doesn't conflict with what the user changed). SVN also allows for multiple working "branches" to be developed independantly then merged back into a central "trunk" later on e.g. one branch for pure DXF/entmake, another for VLISP, and a third for ODCL. Finally, you can load the working files into AutoCAD right from the working directory - no temp copies required.
Sending changes back to the repository can be done in one of two ways. The simplest method is to perform a "commit", where the working copy overwrites the repository copy. This requires the user to take responsibility for updating their own working copy first, otherwise previous changes to the repository copy may be lost. This operation is usually reserved for admin-level users for this reason. The second method is to create a "diff patch". This creates a file with a set of instructions (called a "diff") that indicate the changes to be made to the repository file. This "diff" is then sent to an admin-level user who checks the contents for QA/QC and conflicts with other "diff" submissions. The "diffs" are then collectively applied to the repository copy (usually on a regular schedule) and users are alerted to update their working copies.
How does this apply to us? At the start, I forsee a lot of movement in the code: new functions, new global variables, changes to function names, and so on. Creating diff patches for each of these would be tiresome for the coders which is the reason I suggested isolating each function into its own LISP file. This will allow individual coders to perform their own "commits" to the repository with little fear of mucking something else up. If they are not comfortable with SVN access or don't want to install the SVN client then they can simply submit the file wholesale to a lieutenant to commit. Once the code base has stablised then we need to decide how to proceed. I would suggest we consolidate the functions into a handful of files and change to the diff-submission system, although we could continue with separate files and individual commit operations. We don't need to make the decision immediately - it can be put on hold for a while.
-
dgorsman, related to SVN (Ive put some forethought into the group effort problems); have you seen my post on my LispFileProcessor? Makefiles or batch scripts could make the process of assembling, updating, committing easier.
[ http://www.theswamp.org/index.php?topic=37700.0 ]
Good introduction BTW.
-
dgorsman, related to SVN (Ive put some forethought into the group effort problems); have you seen my post on my LispFileProcessor? Makefiles or batch scripts could make the process of assembling, updating, committing easier.
[ http://www.theswamp.org/index.php?topic=37700.0 ]
Good introduction BTW.
Thanks. And, yes - I was considering the potential for using that for compiling the "trunk" files partway through the project. If separate files are retained then a makefile can be used to create the "trunk" or "release" version up to date. If the fewer-but-larger-files path is taken it can be used to help build the "trunk" then.
-
Project Announcement:
12 hours until the criteria deadline.
-
I left the writeup i was working on at home (sorry) so i will start the Kickoff thread later today.