TheSwamp
CAD Forums => CAD General => Topic started by: Swift on October 23, 2005, 07:53:27 PM
-
After the recent contour topic who would be interested in working on an open source survey package? We could start with the triangulations and contour package first but I think a better start would be a basic survey package
- Import/Export Points
- Traverse/Sideshot/Intersections
- Annotation(Bearing/Distance)/Line&Curve Tables
- Coordinate Transformations/Adjustments
-
My skills as a codesmith are limited at best, but I have access to many resources that may prove useful in such an endeavor. . . awaiting direction
-
I might be able to translate some well-defined algorithms into code, but I know next to nothing about surveying. I assume you'll be wanting to do this in C++?
-
It sounds like an interesting project. I might be interested, depends on what langague is being used.
-
I think the core of the project should be c++ dlls then we can write interfaces in lisp for autocad and intellicad.
-
I'll help. But i know NOTHING about civil so my help would prolly have to be some internal proceds and etc. ...but ill help in any way i can.
-
Interesting, how may I help?
Visual LISP + Visual BASIC (VB6 Enterprise) proficient.
Good with graphics.
Have full MSDN membership, so I have Visual Studio .NET architect et. al. just not proficient yet (oddly enough bought a C# book just yesterday).
Is 'anal retentive' a marketable skill here?
:oops:
-
Luis my friend, read this post (http://www.simplemachines.org/community/index.php?topic=16971.msg140624#msg140624) in its entirety.
:)
-
Does anyone have any experience with xml and LandXML?
-
You can count me in!! Not sure I can provide that much in the way of programming though. I do know a lot about surveying and how surveyors work. I can provide web space w/ all the fix'ns and a cvs via Subversion.
-
I think the core of the project should be c++ dlls then we can write interfaces in lisp for autocad and intellicad.
It might be a good reason to learn c++. What version of c++ will you be using?
-
I think the core of the project should be c++ dlls then we can write interfaces in lisp for autocad and intellicad.
It might be a good reason to learn c++. What version of c++ will you be using?
Cool, I know enough c++ to be completely dangerous.
But seriously, of all the languages I've taken a run at I liked c++ the most, I wish there were more c++ in the curriculum when I studied oo languages at university.
-
I am by no means a c++ guru but I can get around a little bit. I say we stick with ANSI C++ and we can use Bloodshed (http://www.bloodshed.net/devcpp.html) as the compiler of choice.
-
Im cool with that.
BTW, I can shoot my computers foot with Cpp quite easily (I'm still really bad at it.) I'm also really bad Lisp but i know enough to shoot your computers foot with it.
-
Sorry se8en but, personally, I don't want you shooting anything near me. :-P
-
...Dude, im a fricken Marksmen!
-
Is that like a mason? Do you have a secret handshake?
-
...Dude, im a fricken Marksmen!
Who's Mark? And does he know you kiss and tell?
-
eeeeuuuu
-
I think the core of the project should be c++ dlls then we can write interfaces in lisp for autocad and intellicad.
... we can use Bloodshed (http://www.bloodshed.net/devcpp.html) as the compiler of choice.
Those two statements might be compatible for IntelliCAD, but definitely are not for AutoCAD. In fact, depending on which versions of AutoCAD we want to support, we may need more than one version of Microsoft Visual C++. I have version 6.0 which will work for AutoCAD 2000 - 2002. Visual Studio .NET 2002 (which I don't have) is required for AutoCAD 2004+.
-
*Thinking aloud* All interaction with the programs will have to be through lisp (not arx in autocad)... use dlls for whatever reusable code there is ... math for intersections/adjustments ...etc.
-
I see. Let me pose a question for the lisp experts then. Can AutoLISP call functions exported from a standard C (not ActiveX) dll? I know VBA can, but I'm not sure about lisp.
I'm not trying to be a wet blanket, by the way. I just don't want us to make any design decisions now that are going to come back to bite us on the butt later.
-
I see. Let me pose a question for the lisp experts then. Can AutoLISP call functions exported from a standard C (not ActiveX) dll? I know VBA can, but I'm not sure about lisp.
I'm not trying to be a wet blanket, by the way. I just don't want us to make any design decisions now that are going to come back to bite us on the butt later.
No, but you create an activex dll that wraps 'standard' dll exported functions. I do it to access standard windows dlls from lisp.
-
So what is the best way to support both Autocad and Intellicad while still using the same code base?
-
It looks like ActiveX is going to be about the only way to do it (not that there's anything wrong with that :-)).
-
I think using what MP has sugested. HOWEVER, i dont think i know of a way to call a DLL in plain AutoLisp. *thinking*
-
Put core functionality in standard windows dlls. Essentially all the math stuff but no entity modification type code.
Make wrappers for Intellicad in ADS, wrappers for AutoCAD in ARX.
Both (ADS and ARX) can expose functionality to lisp.
Write language agnostic lisp wrappers for IntelliCAD / AutoCAD implementations.
-
And of the graphical interface?
-
And of the graphical interface?
wxWidgets?
-
And of the graphical interface?
wxWidgets?
AutoCAD supports Python?
-
And of the graphical interface?
Forgive me, I've not surveyed in some twenty years. How complicated do "we" imagine the interface(s) might be? iow, someone please name of the typical things a library such as this hopes to address.
-
General statement -- I've seen a lot of ideas get floated for communal effort like this and the number one cause of failure remains the same -- the lack of a document laying all aspects of what the effort actually is. It's like attempting to build a bridge without a set of blueprints. You can't build the bridge no matter the talent of all the workers who are ready to put their muscle into it and all the ideas like 'yeah, gotta be modern truss system' et al.
/evangelism for the day.
-
I'm trying to think of an instance were I'd like to have a graphical interface but none come to mind. Please explain.
-
And of the graphical interface?
wxWidgets?
AutoCAD supports Python?
Sorry. C++ on the brain (there is a C++ port isn't there?).
-
And of the graphical interface?
wxWidgets?
c++
AutoCAD supports Python?
-
I agree with MP; we need documentation. Mark already has the CVS(subversion) up and running, so we can start developing, but we need to get our ideas down on paper first and foremost.
On the topic of Graphical. What were you thinking about using grafix for? ...I was thinking that if we develop in this type of manner:
Task: import a set of ''points'' (comma delimited) into autocad and have those points be marked and labled.
1. call app.
2. app asks where file to import is.
3. app does all ''mapping'' of points.
There wouldnt be a need for graphical at all.
-
There are options on how the points are plotted
- the type of symbol(block) used to represent the points
- is the point to be drawn in 3d
- layer of point symbol
- plot pt#, description, elevation? number of decimal places to use
- plot all points of a numeric range
- plot by point description
- plot by elevation range[/i]
[li]plot within radius - plot by numeric range
-
Even to support the simplest of adjustment routines (compass rule) you'll need somekind of grid to really have a nice appearance.
Same way with Triangulations there are a lot of options involved before any of the math happens
-
MP makes a really good point, and I'll go one further. I think somebody has to take on the role of coordinator, one person who knows what is already done, what needs to be done, and who is working on what.
I nominate Swift.
-
I've never coordinated any software project development but as we've got fond of saying around here ... "He!! we've built a dam, don't sweat the small stuff" :D
That being said we need ideals. I think we need to be able to read/write some already existing packages files. I'm familiar with Carlsons stuff and have more time than I care to admit working with SMI up to version 6 (not sure how much it has changed recently).
So just what do we want this thing to do in the first release?
-
So just what do we want this thing to do in the first release?
Assuming one were working from an adequate software blueprint, prove that the first scaled down, throw away prototype works in AutoCAD and IntelliCAD using typical data produced by the more popular total station units etc.
-
Wow, you'd be surprised by the interest in this thread from all the non logged in lurkers -- 6 as we speak.
Folks like T__ G__ G__ out of __ __.
Hi guys!
<waving.gif>
The RSS feed is giving this thread quite a spotlight far away from the swamp.
-
The RSS feed is giving this thread quite a spotlight far away from the swamp.
True that, but they weren't reading via RSS (they may have initially snagged the post that way).
:)
-
I just mentioned it in consideration if the thread should be moved at some point.
-
I know nothing of surveying really but I have vs2002 pro and vc6 if required for any arx development (if required). I'd also be happy to work on any geometry/math lib's if needed. I've also played with ODBC a bit if your import/export data has this interface.
Cheers,
Mick.
-
If anyone wants a C++ compiler ... here (http://msdn.microsoft.com/visualc/vctoolkit2003/).
Resources (http://msdn.microsoft.com/visualc/default.aspx) for same.
-
If anyone wants a C++ compiler ... here (http://msdn.microsoft.com/visualc/vctoolkit2003/).
Can that version compile the ObjectARX stuff?
-
Doubtful, ObjectARX tends to be compiler and version centric. But it could be used to develop the core dlls, which (as I understood it) are slotted to be standard (non activex) windows dlls.
-
If anyone wants a C++ compiler ... here (http://msdn.microsoft.com/visualc/vctoolkit2003/).
Can that version compile the ObjectARX stuff?
Amazingly it can be made to compile for ACAD 2000(normally requires VC++ 6) if you know what other packages to download from Microsoft. However, the additional packages needed to make it compile for ACAD 2004+(VS.net 2002) are not available.
-
But it could be used to develop the core dlls, which (as I understood it) are slotted to be standard (non activex) windows dlls.
Not set in stone yet.
-
Is the project going to include both intellicad and autocad? Is that "set in stone"?
-
Very true, a premature assumption. Picking the compiler before establishing the overall architecture is folly. I was literally just saying, If anyone wants a c++ compiler ...
:)
-
MP makes a really good point, and I'll go one further. I think somebody has to take on the role of coordinator, one person who knows what is already done, what needs to be done, and who is working on what.
I nominate Swift.
Agreed, a project like this needs a coodinator, a lead.
Swift, if I second the nomination will you accept?
-
Do we think a project this size (It has the potential to be big) should be run by several?
Create the overall specs and seperate into groups with a proj lead in each.
-
Do we think a project this size (It has the potential to be big) should be run by several?
Create the overall specs and seperate into groups with a proj lead in each.
I agree their needs to be a spec (that's an absolute) and there has to be a delegation tree / resposibility matrix. It's simple divide and conquer with accountability.
-
Do we think a project this size (It has the potential to be big) should be run by several?
IMO you still need one person in charge of the whole shabang.
-
IMO you still need one person in charge of the whole shabang.
Agreed. Swift has two nominations.
-
Well I'm out-a-here, talk to you folks in a couple hours if I can.
-
Is the project going to include both intellicad and autocad? Is that "set in stone"?
It doesn't have to be. It might be easier if we concentrated on Autocad now and bring Intellicad in later or vise-versa.
-
IMO you still need one person in charge of the whole shabang.
Agreed. Swift has two nominations.
Alright, I'll do it.
-
I recommend we keep the point DB in simple ascii form, cvs type maybe.
-
And of the graphical interface?
wxWidgets?
AutoCAD supports Python?
WxWidgets is for C++. WxPython is a python wrapper to the WxWidgets library. Sort of like how PyGTK is a python wrapper to the GTK library.
-
Is the project going to include both intellicad and autocad? Is that "set in stone"?
It doesn't have to be. It might be easier if we concentrated on Autocad now and bring Intellicad in later or vise-versa.
That. Right there. That's a serious design flaw in my opinion. If you don't design for your target from the get go you're asking for inevitable problems down the road that inevitably get "fixed" with some cludgy patchwork, ad hoc fixes I've come to refer to as duct tape, popsickle sticks and binder twine. Either it's designed from the bottom up to work exclusively for one platform or for multiple platforms.
Sorry, you've stepped on a nerve, I have seen this movie TOO many times and have been the unhappy participant in those ill fated kinds of efforts. If I don't raise a stink it's my fault, so I've no choice -- I have to say this is plain wrong.
In my opinion of course.
/rant.
-
The only thing I have against plain text files is speed when working with large points sets, but it'll take a little test to see how much of a difference it makes.
-
Could the functions in the API's for IntelliCAD be accurately described as a subset of the functions in the corresponding API's for AutoCAD?
In other words, would it be fair to say, for example, that a lisp program designed for IntelliCAD will work in AutoCAD, but not vice versa, or am I oversimplifying?
-
Is the project going to include both intellicad and autocad? Is that "set in stone"?
It doesn't have to be. It might be easier if we concentrated on Autocad now and bring Intellicad in later or vise-versa.
That. Right there. That's a serious design flaw in my opinion. If you don't design for your target from the get go you're asking for inevitable problems down the road that inevitably get "fixed" with some cludgy patchwork, ad hoc fixes I've come to refer to as duct tape, popsickle sticks and binder twine. Either it's designed from the bottom up to work exclusively for one platform or for multiple platforms.
Sorry, you've stepped on a nerve, I have seen this movie TOO many times and have been the unhappy participant in those ill fated kinds of efforts. If I don't raise a stink it's my fault, so I've no choice -- I have to say this is plain wrong.
In my opinion of course.
/rant.
Thats very true MP, I'll start a poll for a little feed back.
Chuck, I'm not very lispy but I THINK intellicad supports all the Autocad functions but none of the vlisp functions.
-
The only thing I have against plain text files is speed when working with large points sets, but it'll take a little test to see how much of a difference it makes.
Really!! I would have thought reading/writing to an ascii file would be the fastest method. Guess you would have to store the entire file in memory though.
-
The only thing I have against plain text files is speed when working with large points sets, but it'll take a little test to see how much of a difference it makes.
Really!! I would have thought reading/writing to an ascii file would be the fastest method. Guess you would have to store the entire file in memory though.
You can gulp a text stream in one swipe and it's near instantaneous, even on 'large' files. Reading a file sequentially is sloth like in comparison.
But to step back a moment, is the intent to establish a proprietary ascii based file format or, (preferred in my opinion), identify an established industry standard, use that as the basis, and then write plugins as required to translate to said file format *before* the application greater uses the data?
-
If an industry standard format does indeed exist, I vote for using that format.
-
I agree with MP on the design from the get-go issue. We need to develop for one or for all.
And that brings me to... Has anyone talked to someone from Intellicad to see if we can get some info about what native AutoLisp functions are not included or included. Does anyone have Intellacad installed? Who can Beta test this package for us? If we start to establish some intentions and when we contact them they will actualy loan us a version for testing, or libs or even some source to work with as a base ...ohhh, or even the lisp intrip to include our own dll--now that would be saweeet!--. (Cant hurt to ask.)
On the topic of Format i say develop our own or use an existing standard as a starting point for our own. (Faster that way.)
-
An "industry standard format" would be comma delimited values ( .csv ) would it not? Just about every survey package I've ever used could read/write a comma delimited ascii file. Simple and clean, something everyone knows.
-
For data storage you'll have a tough time finding a better format than JSON (http://www.crockford.com/JSON/index.html).
-
There's csv and then there's csv as used by the industry.
For example, is it dumb x, y, z data or is it adorned with point descriptors (eg: BM #27), run descripters (eg: BC [Beginning of Curve], EC [End of Curve]) etc.
There must be an existing standard established that is used by the all the total station manufactures etc. as standard export from said machines and that is what existing software from the Shreiber and Carlsons of the world accept as input. I'm suggesting that is a pragmatic avenue to take rather than inventing our own standard that is based on csv.
Clearer?
:)
-
How about x3d (http://www.web3d.org/x3d/overview.html) as a file format. The specifications might be overkill, but it is capable of holding 2d, 3d and most other cad data.
If size is an issue, what about compressing the file when not in use?
I am considering using it for a project that I might be working on the near future.
-
Whatever format most surveying instruments spit out is the format we need to support for input files.
Once the point data is imported, I think the dwg format should be able to accommodate all of our needs.
-
Good stuff Troy.
As xml is self describing it might indeed be a good for the reasons I briefly touched on (point adornment etc.). While, at this point, it may be overkill, I see nothing wrong with having the capacity to store what the current identified needs are (wait have they been identified?), rather, the problem is when a container or spec cannot host future unknown requirements.
While one might guess I'd now say "yeah, has my vote" no, I say -- "this worthy serious consideration, put it on the list of proposed formats and let us go now and identify what actually needs to be stored now as an absolute minimum, and what possibly be required for the future" -- which should be done first.
Rhetorical and not so rhetorial questions: What are the deliverables? What is the workflow? What minimum data do we need to start with?
Insomnia -- it's a lot more than lack of sleep.
-
Whatever format most surveying instruments spit out is the format we need to support for input files.
Once the point data is imported, I think the dwg format should be able to accommodate all of our needs.
At the dll level, assuming that's the route were going (which has not been finalised or even formally truly floated) it's just the core math -- they know nothing (and should not know) how the data is to be used or stored -- they simply accept input, perform calculations and return results, but are (or should be imo) application agnostic.
/imo
-
For me a typical csv file would contain: PointNumber,Northing,Easting,Elevation,Description
Unless I'm missing something that should take care of any thing you'd want to do in a survey.
From all the packages I've used that have the ability to write a csv file, none would have a problem with this format. ( PointNumber,Northing,Easting,Elevation,Description )
-
Good stuff Mark.
Like I said previously, I really don't know a thing about the requirements for a survey program. I'm just trying to contribute the only way I think I can: Ask the questions that have to be asked, throw alerts on things that don't look right, suggest methodologies that have worked in the past. As most of these things are not application centric, to that end I think I have something to contribute, if nothing other than my bent on sanity checks (which by definition is absurd, oh well).
:)
-
Typical workflow for us is; instrument--> data collector --> PC --> adjustment application --> point file --> CAD/Enginerring application.
I've never seen data come from a total station directly into CAD, I'm not saying it doesn't happen though.
-
Whatever format most surveying instruments spit out is the format we need to support for input files.
Once the point data is imported, I think the dwg format should be able to accommodate all of our needs.
At the dll level, assuming that's the route were going (which has not been finalised or even formally truly floated) it's just the core math -- they know nothing (and should not know) how the data is to be used or stored -- they simply accept input, perform calculations and return results, but are (or should be imo) application agnostic.
/imo
I think you and I are in agreement, but apparently I'm just not expressing my ideas clearly enough. It sounds to me like you are saying the same thing I'm thinking, but evidently the reverse isn't true. :D
-
For me a typical csv file would contain: PointNumber,Northing,Easting,Elevation,Description
Unless I'm missing something that should take care of any thing you'd want to do in a survey.
From all the packages I've used that have the ability to write a csv file, none would have a problem with this format. ( PointNumber,Northing,Easting,Elevation,Description )
This is true and correct and is the established way in my area of exchanging data between companies and clients. Only stipulation that some packages place is a 32 character limit on the Description field.
That said I will bring to light the LANDXML project at http://www.landxml.org/ and https://sourceforge.net/projects/landxmlsdk/
-
Just my opinion, while I think XML is a great tool for storing data, you still need to use a parser. This applies unwanted overhead and complexity to your app. It seems to me from what has been said so far that a csv file is pretty basic, universal and easy to export/import into other apps, to write a parser for this type of csv would be pretty simple and fast to implement with no COM or other unwanted baggage.
-
Who will the end users of this package be? I would expect most of them to be guys with older equipment and software that almost certainly will be able to export simple text files as Mark describe but would be much less able to work with other formats and some, such as our surveyor, who refuse to use other methods when they are available.
-
Just my opinion, while I think XML is a great tool for storing data, you still need to use a parser. This applies unwanted overhead and complexity to your app. It seems to me from what has been said so far that a csv file is pretty basic, universal and easy to export/import into other apps, to write a parser for this type of csv would be pretty simple and fast to implement with no COM or other unwanted baggage.
All that's true, but once we start doing more advanced things like horizontal/vertical alignments, typical sections, cross sections, profiles and dtms then we will need a more defined format such as LandXML. So if we will need it in the future, shouldn't the project be started using it?
-
I am about 40 posts behind right now and will probably do my catch-up tomorrow. Don't have a lot of time so I'm going to combine the two threads. The more platform independant it is, the better IMO. I think it would be great if it worked on intellicad and autocad. Has anyone mentioned MicroSuction? If I remember right, intellicad is open source, what about a Swamp Civil build of intellicad with this bundled? While there are, in my mind, reasons such as ease of design to avoid XML, I think LandXML still might be the way to go. I have seen federal contracts that require LandXML data. More to follow, probably much more. Anyone who knows me, knows that while I may be short on abilities, I'm never short on opinions.
-
Another thing to remember on the coordinate files is that while PNEZD is the format that most of us use, MANY large companies request Point . X. Y, Z,Desc. (Or PENZD) and then you must also be able to create space delimited and comma delimited files. Some data collectors take one, some take the other. If you cannot download your final coordinate file back into the data collectors to complete the field work, you do not have a viable product.
And don't forget the traverse balancing routines. You will need to be able to balance by Compas Rule, Crandal's Rule and Least Squares at a minimum to meet all state requirements. (Lately Least Squares is more and more becoming the prefered method.
And if this thing is going to include a Terrain Package I have a long wish list there too.
-
The thing about balancing routines is importing the various raw data files. I have all the math for Compass, Crandals and Least Squares routines. In fact I already have the least squares solver written,just so happens the method is the same for coordinate transformations, the only difference is the content of the matrices it solves. I however will need some help reducing the calculus involved if I can't find all of my work from college.
I have samples of SMI versions 3-6 and Carlson SurvCE raw data files. We will eventually need samples for all packages we will need to support. We also will need someone with access to various adjustment packages for checks.
On another note I can also adjust GPS Vectors if there is a need for it and level loop adjustments aren't a big deal either.
-
Can I be nosey and ask what this proggy would do?
When our office is running/I'm back at work, could I send you a file that our MX people get from the surveyors? and then see if it the sort of proggy you guys are working on?
Many thanks
T :-)
-
I have a 2 year degree in surveying and have forgotten most of it.
From what I have read it sounds like the push in the future is XML.
But, the instruments will only take csv or ssv files in certain formats.
Sounds like you should build the whole thing around XML and make an import/export routine that will deal with csv and ssv files. Go so far as to ask the user if it is in PNEZD or PENZD. That sounds like it would be the more robust of the options AND make it future friendly as well.
Let me know what I can do to help.
-
I began working on a dll this weekend, it seems I had forgotten everything I knew about c++ dlls . So far I have something like
Struct ‘Point’ with No,X,Y,Z,Desc
A class ‘Pts’ with properties
Vector<Point>
bPtProtect
With Methods
ImportTextFile (To Allow for #,Y,X,Z,D #,X,Y,Z,D comma and space delimited)
ExportTextFile
GetPoint( by pt# return a struct)
GetPoint( by vector index)
GetPointCount(return vector.count)
GetPoint3d(pass byref 5 variables)
EditPoints
ListPoints
TranslatePoints
RotatePoints
TransformPoints
For now I’m going to implement the file dialog boxes with Win32 api. I hope to just use this code as a ‘proof of concept’ so that we can write wrappers for AutoCAD and Intellicad. Also on this first pass I’m going to just implement enough so that we can plot points on the screen. I hope to have it ready in the next couple of days.
Should we also include the CoGo (inverses, intersections, traverse) routines as part of the Pts class or should they be separate? Does an unsigned int allow for enough points (0 to 65535)? The only time I can think that it wouldn’t be more than enough would be for contouring large aerial photography.
Anything thing I missed? Thoughts? Comments?
-
Yeah, what can we do?
-
How is your file parsing skills in c++?
-
non-existant. I was thinking alog the lines of early lisp tools.
-
Ok, let me finish the dll. Then we'll have to wrap it in a activex dll. Then we need a point plotting lisp function.
-
How difficult is it to get the current drawing name and path with lisp?
-
(apply 'strcat
(mapcar 'getvar
'("dwgprefix" "dwgname")
)
)
-
Thanks MP
-
Sorry to be so terse, was just duckin' out for a sandwich.
-
Pardon my ignorance in lisp but...
What is the lifetime of a lisp variable?
If we export a class from the c++ dll and wrap it with an activeX dll and create and instance of it, what is its lifetime? Is it active as long as the drawing is open?
I'm looking for ways to maintain the relationship between the drawing and the coordinate file.
-
.. What is the lifetime of a lisp variable?
I'm looking for ways to maintain the relationship between the drawing and the coordinate file.
Till Overwritten or the Drawing closed. < edit : Global variables that is >
Dictionary may work for you. Accessed from all IDE's
-
... Dictionary may work for you. Accessed from all IDE's
My thoughts exactly.
Swift,
You mentioned needing help parsing the files?
-
... Dictionary may work for you. Accessed from all IDE's
My thoughts exactly.
Swift,
You mentioned needing help parsing the files?
I'll need some Chuck but let me get the framework fleshed out a little more first. Right now I'm playing with dll exports. 'dumpbin' is my friend :D
-
... and make it hard owned and it will survive purging etc.
-
OK, I've hit a wall trying to get std::vector and std::string to export out of the dll I found http://support.microsoft.com/default.aspx?scid=kb;en-us;168958 but I can't seem to get it to work. Any ideals? I'm working with
// The following ifdef block is the standard way of creating macros which make exporting
// from a DLL simpler. All files within this DLL are compiled with the POINTS_EXPORTS
// symbol defined on the command line. this symbol should not be defined on any project
// that uses this DLL. This way any other project whose source files include this file see
// POINTS_API functions as being imported from a DLL, whereas this DLL sees symbols
// defined with this macro as being exported.
//#define POINTS_EXPORTS
//disable warning on 255 char debug symbols
#pragma warning (disable : 4786)
//diasable warnings on extern before template instantiation
#pragma warning (disable : 4231)
//^ as per http://support.microsoft.com/default.aspx?scid=kb;EN-US;168958
#ifdef POINTS_EXPORTS
#define POINTS_API __declspec(dllexport)
#define EXPIMP_TEMPLATE// http://support.microsoft.com/default.aspx?scid=kb;EN-US;168958
#else
#define POINTS_API __declspec(dllimport)
#endif
#include <vector>
#include <string>
struct Point{
unsigned int nPtNo;
double dX;
double dY;
double dZ;
char cDesc[32]; //most data collectors I've seen only support 32 character descriptions
//although we could make this a string and truncate the string in the export function
};
//////////http://support.microsoft.com/default.aspx?scid=kb;EN-US;168958///////
EXPIMP_TEMPLATE template class DECLSPECIFIER std::vector<Point>;
EXPIMP_TEMPLATE template class DECLSPECIFIER std::string;
///////////////////////////////////////////////////////////////////////////////
// This class is exported from the Points.dll
class POINTS_API CPoints {
//class DECLSPECIFIER CPoints{
//////////////////////////////////Private////////////////////////////////////////////
private:
bool bPtProtect;
std::vector < Point > pts;
/* ^^^^^^^^^^^^^^^^^^^^^^^
Under VC 2002 this gives the following warning, which I haven't investigated yet
"c:\Projects\Survey\Points\Points.h(30): warning C4251:
'CPoints::pts' : class 'std::vector<_Ty,_Ax>'
needs to have dll-interface to be used by clients of class 'CPoints'
with
[
_Ty=Point,
_Ax=std::allocator<Point>
]*/
std::string sPath;
/* ^^^^^^^^^^^^^^^
c:\Projects\Survey\Points\Points.h(31): warning C4251:
'CPoints::sPath' : class 'std::basic_string<_Elem,_Traits,_Ax>'
needs to have dll-interface to be used by clients of class 'CPoints'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Ax=std::allocator<char>
]
*/
//////////////////////////////////Public////////////////////////////////////////////
public:
CPoints(void); //new drawing
CPoints(std::string path); //path found in existing drawing
int ImportTextFile(void);
int ExportTextFile(void);
// int ImportCarlsonCrd(); // I have these figured out, I will need samples and or specs
// int ExportCarlsonCrd(); // to support other binary formats
int RotatePoints(void);
int TranslatePoints(void);
int EditPoints(void);
int ListPoints(void);
int AddPoint(Point oNewPoint);
int AddPoint(unsigned int nPtNo, double dX, double dY, double dZ, char cDesc[32]);
Point Getpoint(unsigned int PtNo);
int GetPtIndexCount(void);
Point GetPtByIndex(int nPtIndex);
unsigned int GetHighPointNo(void);
int GetPointNoExtremes(unsigned int &LowNo, unsigned int &HighNo);
//////////////////////////////////VB Wrappers////////////////////////////////////////////
void * __stdcall CreatePoint();
void * __stdcall CreatePoint(std::string path);
void * __stdcall DestroyPoint(void * objptr);
//////////////////////////////////VB Wrappers////////////////////////////////////////////
//bool operator < (CPoints) const;
bool operator < (const CPoints c) const
{ return pts < c.pts; }
bool operator == (const CPoints c) const
{ return pts == c.pts; }
};
-
I don't think you can exp/imp things which are only relevant to the C++ std lib's as the caller/sender has no knowledge of them (say from/to vb), similar to COM interfaces you will probably have to convert/use vanilla type variables such as char[]'s for strings for example.
-
Swift,
You can see I changed a few miscellaneous minor things in your code, but the primary things I did to get it to compile were:
1) Defined operator< and operator== for the point class. Not sure why, but the compiler insisted upon this. Vector isn't a sorted container, so I truly don't understand this one.
2) Removed std::string from the code, and replaced it with char*. I haven't found anything to indicate that it is possible to export std::string.
#ifndef POINTS_H
#define POINTS_H
#ifdef POINTS_EXPORTS
#define DECLSPECIFIER __declspec(dllexport)
#define EXPIMP_TEMPLATE
#else
#define DECLSPECIFIER __declspec(dllimport)
#define EXPIMP_TEMPLATE extern
#endif
#include <vector>
EXPIMP_TEMPLATE class DECLSPECIFIER Point{
public:
// Data
unsigned int nPtNo;
double dX;
double dY;
double dZ;
char cDesc[32];
// Constructors and destructor
Point() {}
Point(unsigned int num, double xVal, double yVal, double zVal, const char* desc) :
nPtNo(num), dX(xVal), dY(yVal), dZ(zVal) {
strncpy(cDesc, desc, 31);
cDesc[31] = 0;
}
virtual ~Point() {}
// Operators
// The compiler was pretty insistent that operator< and operator== be defined
// for the Point class
bool operator<(const Point& p) const {
return dX < p.dX;
}
bool operator==(const Point& p) const {
return (dX == p.dX) &&
(dY == p.dY) &&
(dZ == p.dZ);
}
};
// Explicit instantiation of vector<Point>
EXPIMP_TEMPLATE template class DECLSPECIFIER std::vector<Point>;
EXPIMP_TEMPLATE class DECLSPECIFIER CPoints {
private:
bool bPtProtect;
std::vector<Point> pts;
char* cPath;
public:
CPoints(); //new drawing
CPoints(const char* path); //path found in existing drawing
int ImportTextFile();
int ExportTextFile();
// int ImportCarlsonCrd(); // I have these figured out, I will need samples and or specs
// int ExportCarlsonCrd(); // to support other binary formats
int RotatePoints();
int TranslatePoints();
int EditPoints();
int ListPoints();
int AddPoint(Point);
int AddPoint(unsigned int nPtNo,
double dX,
double dY,
double dZ,
char cDesc[32]);
Point Getpoint(unsigned int PtNo);
int GetPtIndexCount(void);
Point GetPtByIndex(int nPtIndex);
unsigned int GetHighPointNo(void);
int GetPointNoExtremes(unsigned int &LowNo, unsigned int &HighNo);
//////////////////////////////////VB Wrappers////////////////////////////////////////////
void* __stdcall CreatePoint();
void* __stdcall CreatePoint(const char* path);
void* __stdcall DestroyPoint(void* objptr);
//////////////////////////////////VB Wrappers////////////////////////////////////////////
bool operator<(const CPoints& c) const {
return pts < c.pts;
}
bool operator==(const CPoints& c) const {
return pts == c.pts;
}
};
#endif
-
I take back point #2. Check which version of the C runtime you are linking against. I found a usenet post that said the DLL version of the runtime already exports std::basic_string<char>, so I checked and VC++ had set my DLL project up to link to the multithreaded version by default. I switched it to Multithreaded DLL, swapped the std::string back in place of char*, and it compiled with no problem.
-
Thanks Chuck. I'm working on basic file stuff now. I hope to have a first try ready soon.
-
Now remeber im still in the learning process so pardon the question. Whats the diff between these: #ifndef & #ifdef?
-
#ifndef <- If macro is NOT defined
#ifdef <- If macro IS defined
-
Ah gotcha. Thanx
-
ok, I have a frame work in place and working using win32 api calls to select and parse a comma delimited text file (Thanks Cornbread) I have it compiled in VC6 for the moment if anyone wants to work on the arx for inserting blocks with attributes code. Also if anyone has a lisp routine laying around that does the same I could use it to work on the SDS for Intellicad.
-
The AcadUtilities class implemented in AcadUtilities.cpp contains the core functionality for inserting blocks (amongst other things). The other functions in that class will probably be useful later on in the project as well. The other files contain support functions and classes.
The functions in AcadUtilities that add objects to the database always assume the objects are to be added to modelspace. If this turns out to be too inflexible, it would be easy enough to modify. We probably should make that decision up front though, as changes to the interface will necessitate changes to any client code.
-
Thanks Chuck, I'll see what I can do with it tonight.
-
Here is a sample of how to use what I posted yesterday:
#include "AcadUtilities.h"
void foo() {
AcadUtilities acadUtils(curDoc()->database());
// Import a layer
// importLayer searches through the file specified by the LAYERS_FILE constant
// until it finds a layer name that matches the argument. Then uses
// the data in the layers file to create the layer in the current dwg.
// Layers file format is LayerName,Color,Linetype
if(!acadUtils.importLayer("MyLayer")) {
acutPrintf("\nUnable to import layer: MyLayer");
acutPrintf("\nAborting!");
return;
}
// Import a block definition
// First argument is file name. Second is the name to give the block
AcDbObjectId blockObjId = acadUtils.importBlock("MyBlock.dwg", "MyBlock");
if(!blockObjId) {
acutPrintf("\nUnable to import block: MyBlock.dwg");
acutPrintf("\nAborting!");
return;
}
// Insert an instance of the block
// Arguments are
// ObjectId of block table record,
// Insertion point,
// Scale,
// Rotation,
// Layer to insert onto
acadUtils.insertBlock(blockObjId,
AcGePoint3d(0, 0, 0),
AcGeScale3d(1, 1, 1),
0,
"MyLayer");
// Draw a line
// Start point,
// End point,
// Layer
acadUtils.addLine(AcGePoint3d(0, 0, 0),
AcGePoint3d(1, 1, 0),
"MyLayer");
// Draw a box
// Lower left corner,
// Upper right corner,
// Layer
acadUtils.addRectangle(AcGePoint3d(0, 0, 0),
AcGePoint3d(1, 1, 0),
"MyLayer");
// Draw text
// Insertion,
// Height,
// Rotation,
// Horizontal alignment,
// Vertical alignment,
// Text string,
// Layer
acadUtils.addText(AcGePoint3d(0, 0, 0),
0.09375,
0,
AcDb::kTextMid,
AcDb::kTextVertMid,
"SAMPLE TEXT",
"MyLayer");
}
[edit]formatting went a little wonky[/edit]
-
Hi Chuck,
Can you change the Linetype adder in the Utility to have this sort of functionality ?
... instead on automatically using acad.lin
(setq linTypeFile (if (= acEnglish (getvar "Measurement"))
(findfile "acad.lin")
(findfile "acadiso.lin")
)
)
...
... >>
edit : translated the magic number stuff
-
Good catch Kerry.
AcDbObjectId AcadUtilities::importLineType(const string& lineTypeName) {
// Does the linetype already exist?
AcDbLinetypeTableRecordPointer lineTypeRecord(lineTypeName.c_str(),
_pDb,
AcDb::kForRead);
if(lineTypeRecord.openStatus() == Acad::eOk)
return lineTypeRecord->objectId(); // Yep. It's already there. Use it.
string linetypeFileName;
if(_pDb->measurement() == AcDb::MeasurementValue::kEnglish)
linetypeFileName = "ACAD.LIN";
else
linetypeFileName = "ACADISO.LIN";
if(_pDb->loadLineTypeFile(lineTypeName.c_str(), linetypeFileName.c_str()) == Acad::eOk) {
AcDbLinetypeTableRecordPointer lineTypeRecord(lineTypeName.c_str(),
_pDb,
AcDb::kForRead);
if(lineTypeRecord.openStatus() == Acad::eOk)
return lineTypeRecord->objectId();
}
acutPrintf("\nUnable to load linetype: %s", lineTypeName.c_str());
return AcDbObjectId::kNull;
}
-
Thanks Chuck,
That should keep us folk over the pond happy .. :)
-
This is mostly for Swift. I forgot you specifically needed to deal with attributed blocks. Here is a snippet out of a larger program that demonstrates how to do that.
// Insert the footing mark
AcDbObjectId blockRefId = _acadUtils.insertBlock(blockObjId,
markInsertion,
AcGeScale3d(dimScale, dimScale, dimScale),
0,
COLUMN_MARK_LAYER);
// Open the newly inserted block reference so it can be manipulated
AcDbObjectPointer<AcDbBlockReference> footingMark(blockRefId, AcDb::kForWrite);
if(footingMark.openStatus() != Acad::eOk) {
acutPrintf("\nUnable to open footing mark for write.");
return;
}
// Determine footing mark
double width, length;
width = centerToLeft + centerToRight;
length = centerToBottom + centerToTop;
ostringstream os;
if(width == length)
os << "F" << int(width / 1.2);
else
os << "F" << int(width / 1.2) << "x" << int(length / 1.2);
string footingMarkText = os.str();
// Determine t/ftg elevation
char szFootingElevation[25];
acdbRToS(elevation, 4, 4, szFootingElevation);
string footingElevation(szFootingElevation);
// Add the leading zero if the elevation is expressed in inches only
if(footingElevation.find("'") == string::npos) {
ostringstream os;
if(elevation < 0) {
os << "-0'-" << footingElevation.substr(1);
}
else {
os << "0'-" << footingElevation.substr(0);
}
footingElevation = os.str();
}
// Remove the inch marks from the end of the elevation
footingElevation = footingElevation.substr(0, footingElevation.length() - 1);
// Append and set the attributes
AcGeMatrix3d transMat = footingMark->blockTransform();
AcDbObjectIterator* pIterator = footingMark->attributeIterator();
for(pIterator->start() ; !pIterator->done() ; pIterator->step()) {
AcDbObjectId attributeObjId = pIterator->objectId();
AcDbObjectPointer<AcDbAttribute> attribute(attributeObjId, AcDb::kForWrite);
if(attribute.openStatus() != Acad::eOk) {
acutPrintf("\nUnable to open attribute reference for write.");
continue;
}
char* pszTag = attribute->tag();
string tagString(pszTag);
delete pszTag;
if(tagString == "FTG_MARK") {
attribute->setTextString(footingMarkText.c_str());
}
else {
if(tagString == "COL_MARK") {
attribute->setTextString(columnMark.c_str());
}
else {
if(tagString == "T/FTG") {
attribute->setTextString(footingElevation.c_str());
}
}
}
}
delete pIterator;
-
Should I assume this horse is dead and stop kicking it?
-
Should I assume this horse is dead and stop kicking it?
Oh, No not yet. I'd just missed your post yesterday. Sorry.
-
Just curious. Things have been real quiet on this front, and I didn't know if it was from a lack of interest or simply a lack of free time.
-
May I ask....
Is only Chuck and Swift.... working on this?
There is a project [decent] in Spanish, 97% as the one intended to be written here.... coded in ARX/DBX/MFC
And here is the link:
http://topoligonar.galeon.com/
-
As far as I'm concerned anyone and everyone is welcome to participate. I've been side tracked lately on different things and haven't been able to work on this much.
What I have in mind is get an outline together of what functions we want and then write the symbolic math and pseducode out for those functions. Then anyone who wants to help even if they aren't completely familiar with the field will be able to contribute code.
-
http://topoligonar.galeon.com/
Wish I spoke spanish
-
Wish I spoke spanish
:-)