Search Results

Search found 4 results on 1 pages for 'awmross'.

Page 1/1 | 1 

• Find all compilation errors in a Delphi project

  - by awmross

  I am doing some refactoring of my Delphi project. I want to be able to make a change, then see all the places in the project that break due to that change. Similar to how Eclipse lists all the compile errors for a project (in Java). In Delphi, I can make a change, then recompile my project, but the compiler stops when it finds the first Unit that does not compile. I have to fix that Unit, compile again, which will then show me the next error, etc etc. I want to be able to see all the compile errors in the project at once. Then I can decide if the change is worth doing or not. For example, if the change will require hand fixing of 50 separate source files, it's not worth doing. But if it only breaks 2 files then that's an easy change to make. Is there any way to do this in Delphi? Can I tell the compiler to keep going even after finding a Unit that does not compile? I am using Delphi 2010

  Read the article

• Delphi : Handling the fact that Strings are not Objects

  - by awmross

  I am trying to write a function that takes any TList and returns a String representation of all the elements of the TList. I tried a function like so function ListToString(list:TList<TObject>):String; This works fine, except you can't pass a TList to it. E2010 Incompatible types: 'TList<System.TObject>' and 'TList<System.string>' In Delphi, a String is not an Object. To solve this, I've written a second function: function StringListToString(list:TList<string>):String; Is this the only solution? Are there other ways to treat a String as more 'object-like'? In a similar vein, I also wanted to write an 'equals' function to compare two TLists. Again I run into the same problem function AreListsEqual(list1:TList<TObject>; list2:TList<TObject>):boolean; Is there any way to write this function (perhaps using generics?) so it can also handle a TList? Are there any other tricks or 'best practises' I should know about when trying to create code that handles both Strings and Objects? Or do I just create two versions of every function? Can generics help? I am from a Java background but now work in Delphi. It seems they are lately adding a lot of things to Delphi from the Java world (or perhaps the C# world, which copied them from Java). Like adding equals() and hashcode() to TObject, and creating a generic Collections framework etc. I'm wondering if these additions are very practical if you can't use Strings with them.

  Read the article

• Enumerate all paths in a weighted graph from A to B where path length is between C1 and C2

  - by awmross

  Given two points A and B in a weighted graph, find all paths from A to B where the length of the path is between C1 and C2. Ideally, each vertex should only be visited once, although this is not a hard requirement. I supose I could use a heuristic to sort the results of the algorithm to weed out "silly" paths (e.g. a path that just visits the same two nodes over and over again) I can think of simple brute force algorithms, but are there any more sophisticed algorithms that will make this more efficient? I can imagine as the graph grows this could become expensive. In the application I am developing, A & B are actually the same point (i.e. the path must return to the start), if that makes any difference. Note that this is an engineering problem, not a computer science problem, so I can use an algorithm that is fast but not necessarily 100% accurate. i.e. it is ok if it returns most of the possible paths, or if most of the paths returned are within the given length range.

  Read the article

• Is there a way to log every gui event in Delphi?

  - by awmross

  The Delphi debugger is great for debugging linear code, where one function calls other functions in a predictable, linear manner, and we can step through the program line by line. I find the debugger less useful when dealing with event driven gui code, where a single line of code can cause new events to be trigerred, which may in turn trigger other events. In this situation, the 'step through the code' approach doesn't let me see everything that is going on. The way I usually solve this is to 1) guess which events might be part of the problem, then 2) add breakpoints or logging to each of those events. The problem is that this approach is haphazard and time consuming. Is there a switch I can flick in the debugger to say 'log all gui events'? Or is there some code I can add to trap events, something like procedure GuiEventCalled(ev:Event) begin log(ev); ev.call(); end The end result I'm looking for is something like this (for example): FieldA.KeyDown FieldA.KeyPress FieldA.OnChange FieldA.OnExit FieldB.OnEnter This would take all the guesswork out of Delphi gui debugging. I am using Delphi 2010

  Read the article

1