As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The company I work for has an internally developed Word2003/VBA application that's already about 6.5 mb in size and they're looking to add an additional 200+ macros to it, which, I'm assuming, will make it much larger. This seems to me to be a terrible idea, but finding resources to redevelop the tool with VSTO or some other more useful technology will be a challenge.
So here are my questions:
Is it okay, in a pinch, to have a
business dependency on a Word
template with macros that's 10, 20,
or 30 mb?
Is there a Microsoft-defined or
suggested limit (file size, number of
macros, level of complexity) to how
far you can/should extend a VBA app
before it becomes unusable?
In essence, I'd like to know if there is a compelling technical reason to bite the bullet and redevelop this app.
This will give you the limits of Word 2003/VBA: Operating parameter limitations and specifications in Word. Given the limit is 150 macros, it doesn't look like they will be able to continue to use this to add 200+ macros.
I would look at moving some of those macros to an Add-in. Still VBA, but can be used on multiple files and gets the code away from the data (which is a programming win, generally).
--Edit--
As for scaling and size... I think it's all in the design. If it is thrown together, performance will suffer. The file can handle the overall size, but there are limits to Module size (64k), and procedure size (not well documented, but the IDE will let you know when you've hit it). If you start to approach 30mb of text only then you're going to want to find another solution.
You haven't mentioned security, but since this has to do with medical information it should be said that VBA is not secure. If the code is proprietary, and being offered to outside sources you might want to wrap it up in an .xll and install as an add-in. This might actually offer a faster runtime as well.
I know this is an old question. But its seems unlikely there were 200+ macros. Unless they've made every function, or sub a seperate macro, instead of putting them all in the one Macro.
You can write a VBA application within a word macro. But this doesn't sound like it was. Its just a a bunch of macros.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a bunch of C code accessing database (Oracle, DB2 and Sybase) through Embedded SQL : the base code is the same, but with three different precompilers, three sort of executables are built, one for each database/platform.
I works perfectly fine, but we need now migrate to a solution using ODBC access.
The problem is : what tools / api can be used ? A direct way seems to write a custom precompiler (or modify an existent) to wrap all SQL and host variables calls to calls on an ODBC connection.
Can somebody recommend tools for that task or api to keep it simple ?
Or is it a simpler way, another approach ?
Thank you
As is usual for such situations, there are likely no off shelf answers; people's codebases always have a number of surprise in them, and the combination prevents a COTs tool from ever being economical for individual situations.
What you want is a program transformation system (PTS), with a C front end, that can be customized to parse embedded SQL. Such tools can apply source-to-source rewrite rules ("if you see this pattern, then replace it by that pattern") to solve the problem.
These tools require some pretty technical effort to configure. In your case, you'd have to adjust a C front end to handle embedded SQL; that's typically not in C parsers. (How is it that you can process this stuff in its current form?) You'll have trouble with the C preprocessor, because people do abusive things with it that really violate a parsers nested-structures-view of the universe. Then you'll have to write and test the rules.
This effort is a sunk cost to be traded against the effort of doing the work by hand or some more ad hoc scripting (e.g., Perl) that partially does the job leaving you to clean it up. Our experience is that it is not worth the trouble below 100K SLOC, and that you have no chance of manual/ad hoc remediation above 1M SLOC, and in between your mileage will vary.
At these intermediate sizes, you can agonize over the tradeoffs; that costs energy and time, too. Sometimes its just better to bite the bullet and do it any way you can an clean it up.
Our DMS Software Reengineering Toolkit is one of these PTS. It has a customizable C parser and preprocessor, precisely to help deal with these configuration troubles. The other PTSs mentioned in the Wikipedia article, do not, I beleive, have any serious C parser associated with them. (I'm the guy behind DMS).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been working on an application from past 4 months and it's very much depends on Google Maps on iOS platform. Recently one of my friends raised a concern that what if Apple Inc. decides to use a different Map provider?
It turns out after few searching on internet that Apple is going to replace Google Maps with some new advance 3D maps build by company called C3. (One of the researched resource). Well now I am worried of my already written code,
Should I delay my development work until this new technology gets in? or just wait until Apple announces officially.
Thanks
This is a common dilemma in programming, and there's a common solution too. Develop your own primitives - whether you need to display overlays, show landmarks, draw polygons and lines, do everything through stubs in your own code. If the underlying platform has to change, you then have a few well-known places to update to the new API.
Be very strict about not accessing the underlying API anywhere that isn't in your wrapper layer, and it should be straight-forward to change to a different later. Not free, of course, but so long as it's possible to implement the primitives you need in the new layer, you just need to change those, and can leave the rest of your project untouched.
It's not worth losing months' of having a finished project to avoid this situation.
Edit: This approach has another benefit - if you end up writing multiple primitive layers for different APIs, you may be able to let the user pick between them: you may have a (more expensive) higher-quality map layer which you charge for, and a cheap/free one which you don't - allowing people free access to a lower-quality version, and letting them buy an upgrade to the better maps. Or ... there are lots of possibilities. It's the same pattern some applications take with data-persistence layers, letting people run the same application on top of differing data platforms. There are lots of examples of this patterm.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to program with a friend (or a couple) out of the same dropbox folder for a project. I want to put all the assets in the same folder, including config and db files. What I really want to know, is why this might be a bad idea.
I can already think of a bunch of positives:
Quickly sync work. As in, almost instant sync. Dropbox, I've noticed, really is that fast that it is almost like working local.
Program multiple parts at the same time
Dropbox is fast enough to allow one person to add a method, and then another person ad theirs a moment after
Eclipse or Gedit both check for changes in the files so we won't accidentally end up with a conflict.
This isn't a substitute for proper source control and versioning, which we would still use Git for. Dropbox does have 30-day versioning, but for obvious reasons, it is no substitute.
I think this is especially powerful in the beginning when this are changing so fast that every team member having the exact same copy of everything is very important. This is a Rails apps if that matters.
Don't use Dropbox for that, because you'll be on the phone/IM/whatever trying to figure out who is going to edit a particular file (no concurrency AND no checking out!). Use a concurrent versioning system like GIT or Mercurial. There are tons of other advantages. On the downside for Dropbox, you will end up with "conflicted files" all around, which you won't know what to do with much.
The other advantages to a real version control system are well-known. Here's a list from some random blog:
File space.
Let’s say your code
changes 10% each week. Under the
“folder backup” method, each week
you’re saving 100% of the code. Using
a proper VCS, you’re only saving 10%
of your code. I know hard drive space
is cheap, but it’s not free and I
never seem to have enough.
History.
The key to VCS, in my opinion, is
being able to document your changes in
more granular level than a file called
“Changelog.txt” that might not get
changed whenever you work on your
code.
Bug-location:
Let’s say you find
a bug in a method. You search the
history for that file and let the VCS
runs the diffs for you.
Complete
freedom to change code.
You don’t have
to worry about breaking something, or
removing possibly useful code. Before
I moved to VCS, I used to comment out
old code liberally but keep it ‘cos I
might need it. This quickly becomes a
PITA.
If you use git, there are several providers for free or cheap online repo.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I have seen some people who refuse to use Interface Builder and prefer to make everything using code. Isn't this a bit tedious and doesn't it take longer? Why would people do that?
This is usually a holdover from working in other environments with other UI builders. A lot of UI builder programs are viewed as newbie hand-holding at best and outright harmful at worst. Interface Builder is unusual in that it's actually the preferred way to create interfaces for the platform.
Some people don't like mixing code functionality in interface designs. Another example is when flash devs would include lots of code snippets directly in the stage (fla files), rather than in separate .as files. With xib it's not as big of a problem, since they are xml and can be merged quite easily when using source control. I personally like using xib's because we have a team of devs and designers -- splitting up the work load is nice. The designers can easily port their photoshop/fireworks designs into xibs and we can focus on the functionality.
Sometimes you want to do something that the UI builder can't quite handle (these situations aren't common, but they do come up now and then). Sometimes you may feel you have better control over what's happening when you write the code yourself. Me, I prefer to let the UI builders do it as much as possible, but sometimes it doesn't always work that nicely, and I sometimes have had to write the code myself.
Possibly because the Interface Builder is another tool to understand. Also, it's useful to know how to do things programmatically in case nibs don't give you enough functionality.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
With the new 2007 versions of MS-Office, Microsoft started to "threaten" VBA with VSTA. Since VBA is pretty commonly used, what do you believe its future is in terms of scripting development for the next 3-5 years?
Or, will it be killed suddenly, like VB6?
Autodesk also dropped it (kind of) upon hearing news from MS.
I'd suggest that VB6 wasn't killed suddenly. Official MS support, perhaps, but still the community is alive for both VB6 and VBA here on SO.
As with any technology with a WIDE user/customer/3rd party vendor base, it will take a long time for VBA as a scripting technology to fade away. I would imagine that it will take years for its successor to fully overtake VBA.
Agree with Dick Kusleika about deployment
The problems with deprecating VBA are:
Ease of deployment
Visual Studio - another IDE to learn
For the huge base of working, business-critical VBA apps, where nothing will be added by .NET, why would one want to spend the effort and time migrating?
With VBA, non-developers can knock up quick useful applications within Excel/Word etc. You can't do this with .NET/VSTO.
It will die, IMO, but not suddenly. Excel used to have a macro language called XLM - basically a keyboard playback on steroids. XLM is still supported, and there's easily a dozen people who use it. That's why I think VBA will be around for quite a while. It won't be updated, supported, and maybe not even acknowledged, but it will be available.
Sooner or later MS will integrate .NET with Office apps and fewer people will care about VBA. Right now, I can put some VBA in an Excel spreadsheet, send it to a client, and deployment is done. I can tell the IT department it's an Excel workbook with macros, and they don't feel threatened because they don't know any better. When .NET has deployment options that simple, I'll use it instead. That day will come and VBA will slowly start fading away.
The language has changed & the way things were done (i.e. drag/drop form, create a macro, modify a few line & you are done) will also change.
It won't remain a tool, which a non-developer will find easy to use.
Object model should remain same for basic stuff (Workbook, Worksheet, Range) etc.
New set of things will get added & that will change the object model & hence new learning (e.g. Ribbon Interface)
Not to forget, .net brings in its own concepts/complexity.