My Definitions: script: A script contains one or more executable records which may also include other scripts. executable record: An executable record contains a header and a data section. data section contains a struct representing the values of the executableID. (currently the data section is binary data that gets converted by the script engine) header contains sourceID, executableID, sizeof(header + data section). I have thousands of modular scripts that do specific tasks and that could be used by other scripts. For example: MainScript01 -DoSomethingA -DoSomethingB -DoSomeThingC MainScript02 -DoSomethingA -DoSomethingD --DoSomethingC I would like to view the scripts in a tree. I would like to store the scripts in a database or other text based container. If possible in ASCII format for easy editing outside the script engine application. Question: What are some specific possibilities that I could use to store scripts? I am trying to figure out what type of table(s) and fields I should have. -one table holds them all? (cannot easily update structures in the Data field) table definition: ScriptID, ScriptRecordNo, TotalRecords (in this ScriptID), Comments, Data (byteArray of executableID), Index (automatically generated by database), (other control fields) -separate tables? -Mainscripts (using foreign keys to subscripts and executableIDs?) -subscripts (using foreign keys to subscripts and executableIDs?) -each type of executableIDs (one field for variable in the struct makes changing structs and values easier) I would like some pros and cons if possible. Thanks

Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

modified on Tuesday, February 10, 2009 11:10 AM

JudyL_FL wrote:

It's not unprofessional, it just shows that you don't quite get the point of using a DLL versus a static library. some of the differences are: for a DLL: 1) seperate storage from exe 2) multiple exes use the same code 3) to update, change one file 4) usable by exes created with different compilers for a static lib: 1) built into exe 2) each exe uses the built-in code 3) to update, each exe must relink 4) exe must use same compiler as lib (usually)

Wow :omg: , I finally learned something that I did not intend to :) . Just kidding, I am working on a large project and now I know why we are in DLL-hell. Your explanation was great.

Michael If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

I am trying to find out what functions are called for each task of my program. The Visual Studio 2003 .NET solution consists of 8 projects, several hundred classes, and many functions. :(( I know I can just set a breakpoint and step through each line of code writing down each function I encounter but there ought to be an easier way. :) How should I go about this task as I have at least 20 actions I need to report? Example: I Select: File->New Report generates: function A, functions B, function D, etc. I Select: File->Edit Report generates: function A, functions C, function D, etc. I am open to ALL soultions. Thanks in advance

Michael If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

modified on Saturday, April 19, 2008 10:36 PM

First of all thanks for your reply. I am new to add-ins and VSTO. I only wrote the code behind the worksheets for my personal testing needs but my boss saw this and wants everyone to use this format. Hence the 15+ extra workbooks. I am now trying to re-write my code more efficiently (on my own time) as to make maintenance easier on me (and hopefully my test successors).

Dave Kreskowiak wrote:

I think you're taking the wrong approach. If the code needs to work with data from other files, it's the data that needs to be brought to the code, not the code to the data. Your code should be in one spot, and have the ability to use data from any workbook that you chose.

The code does not need to work with data from other files. All the data needed is already contained within each workbook.

Dave Kreskowiak wrote:

redjoy wrote: 2. Would an Excel add-in be appropriate? That depends on what your code is doing and what your business process dictates.

The format of each Workbook is the same. The code for each workbook is identical. I use my workbook for analysis purpose and generate a report for each of my workbooks (CSCI). I execute some code based of values in various columns for each row in worksheet 7. unique to each workbook: Columns A-D are used for showing my requirements, test cases and test conditions. The same in each workbook: Columns E and F are used to show the status of completeness and performance of current requirement. Column G shows the platform the current test case runs on (A, B, Both). Columns H and I shows the test result (P, F, N/A) for platform A chosen in G. Columns J and K shows the test result (P, F, N/A) for platform B chosen in G. Columns I-P: not important to code. Code behind Worksheet 7 for example (pseudo code):

Sub Worksheet_Changed(target as range) 'changes the color coding of active row based on columns E through K.
if a2<>""then
if e2="Complete" and f3="Met" then set the background colors of a2:p2 to GREEN.
...code for color RED.
...code for color YELLOW.
else color WHITE.
end if
else
if g3 = "A" and h3="P" and i3="P" then set the background colors of b3:i3 to GREEN.
... code for color RED.
else color WHITE.
end if
end if

Code behind worksheet 8 copies portions of worksheet 7 to worksheet 2 and 6 and updates a database with the content of worksheet

Problem: Currently I have 12 Excel workbooks (each with 7 worksheets). The data is identical in nature. The common part is the VBA code. Every time I have to make a change to one of the worksheet's VBA code, I need to copy the changes to the other workbooks. I can use either the Excel buit-in VB editor, or any flavor of Visual Studio. I would like to be able to make the modification only once and have the workbooks reference the code instead of copying and pasting to each workbook. Question(s): 1. Is there a way that I can have one central location for the VBA code? 2. Would an Excel add-in be appropriate? 3. Should I program using VS (VSTO)? I am open to any approach to this problem.

Michael If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

modified on Friday, December 07, 2007 3:25:20 PM

try this: #region 'Some text comment explaining the enclosed code, i.e., Helper methods ...put code to collapse here... #endregion

Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

Thanks. You would not happen to know what I could search for, would you? [Edit] I will look in my MSDN subscription and see if they have a patch.

Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

Chris Austin wrote:

But, until MS allowed us to download a Super Secret Patch (SSP ) it (the IDE and Compiler) crashed almost once an hour when working with a very large solution. After the SSP it only crashed a few times a day. The odd thing was the same solution did not crash in VS.net 2003. Color me unimpressed with 2005 thus far.

What and where is this SSP for download?

Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

Thank you. I know that VS2005 converts VS2003 solutions and projects. What I am really looking for is a way to remove any files that are not needed or not used by any projects. The previous developers just pulled in all files from a directory into source control. I am really trying to cleanup the source code as well, i.e., remove unnecessary references to other files that are not needed. Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

I am converting a VS2003 solution (several hundred files) with 10 project to VS2005. At the same time I would like to remove any files that were generated but are not needed or not used. I started by creating a blank solution in VS2005 and adding one project. Several developers were stuffing #includes everywhere, thus creating dependencies that prevent me from pulling each project in one by one. Does anyone know of a better way to do this? Thanks, Michael ﾠﾠﾠﾠﾠﾠﾠﾠ ﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

See my previous message: http://www.codeproject.com/lounge.asp?select=1547238&forumid=1159&fr=732.5&df=100&msg=1547238[^] Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

John Cardinal wrote:

Can't speak for c++ but it's totally usable for c#, just a slow IDE is really the only serious problem.

Our PC's had 512MB memory. Our systems would come to a screeching halt whenever we loaded our solution with VS2005. We recently added 2GB memory (total 2.5GB) and now we no longer experience this problem. It actually loads the solution faster than in VS2003. Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

Gabriel 2 wrote:

Oh, I get the idea, I love iteration!!! for (i = 2; ; ++i) System.Console.WriteLine ("XP SP" + i + " is better than XP SP" + (i - 1));

Unless you have int i = 1; declared or if you have compiler option set for loops :), in VS2005, it should read: for (int i = 2; ; ++i) System.Console.WriteLine ("XP SP" + i + " is better than XP SP" + (i - 1)); I am just mentioning this because we convert our projects from VS2003 and this was a major item for compiling. We used the compiler option :(( Michael ﾠﾠﾠﾠﾠﾠﾠﾠﾠ\|/ ﾠﾠﾠﾠﾠﾠﾠ^O^O^ ——o00o—0—o00o—— If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein

Food for thought: I would like to know EVERY directory/file entry on my hard drive. I know that I can write a prog that traverses the entire tree, but I was reading that all information concerning directories/files, i.e., date (created, modified, last accessed), attributes, etc. are contained in meta files (MFT). Has anyone looked at this. I think that reading the MFT would be a faster solution than traversing the tree. Michael If we knew what it was we were doing, it would not be called research, would it? --Albert Einstein