Simpler Developer Toolkit

Belias

Hi everyone, i was doing a manual merge of a big set of objects, and i was also bored to expand the toolkit tree: why? because when merging forms and reports, the tool marks them as changed even if only xpos and ypos are modified.
I don't want to forgot some property, so i have to open each control or menus in menusuites and check it to find that only the position is modified.
i wrote this simple codeunit to import in the devtool database and run it in order to make 0 eache "x" and "y" fields in the Field/control table of the toolkit. \:D/
no more red objects!!ahah!!

OBJECT Codeunit 50000 FieldControModification
{
  OBJECT-PROPERTIES
  {
    Date=29/04/09;
    Time=13.41.53;
    Modified=Yes;
    Version List=;
  }
  PROPERTIES
  {
    OnRun=BEGIN
            TBFieldControl.SETCURRENTKEY("Version No.","Object Type","Object ID","No.");
            TBFieldControl.SETFILTER("Object Type",'Form|Report');
            TBFieldControl.FIND('-');
            REPEAT
              TBFieldControl.X := 0;
              TBFieldControl.Y := 0;
              TBFieldControl.MODIFY;
            UNTIL TBFieldControl.NEXT = 0;
          END;

  }
  CODE
  {
    VAR
      TBFieldControl@1000000000 : Record 99003606;

    BEGIN
    END.
  }
}

DenSter

When xpos or ypos are different there is a difference, and the objects are not the same. Personally I would want to know about that when merging objects. Setting all values to 0 is not going to help out there at all, or am I missing something?

Belias

usually, when designing form, i design the layout from the designer (i compare it looking at the "visual" position of controls) and then add the code, so i don't want to see what is the perfect position of the control.

DenSter

Won't setting all of those properties to 0 then put all controls in the same possition, all overlapping eachother?

Belias

i was doing a manual merge of a big set of objects,

maybe this phrase is not clear...
i am MANUALLY merging the objects, i mean: i use the tool as a text comparer in order to put manually the modifications

DenSter

Yes I understand the process of manually merging form objects. You also said that you set the xpos and ypos properties to 0 for all controls. Merging two form objects with all controls at the 0-0 position will result in a form with all controls at the 0-0 position, which can hardly be your goal. Unless of course all that you do is compare the text objects, and then manually copy the differences in your target object.

Belias

Maybe i found a good way to explain..listen
I Drag&Drop manually textboxes and other visual objects, therefore, xpos and ypos are set when i "move" the controls. The only thing i need to know is if some texbox have been made not visible/editable or something else.

P.S.: sorry for the english...hope to be more clear this time.

DenSter

I'm glad you found a way you made it easier for yourself, and it's great that you're sharing it, but I still don't get it. When you say 'merge an object' you must mean a completely different thing than I do. When I merge two objects I take two objects with differences and create one final object text file out of those two files, which I then import back into the NAV database. Putting all controls at 0-0 does not help at all for me, in fact all it does is hide differences in position, something that I want to know about. Like I said, you must only look at the differences and manually modify the objects in the object designer. That's how I used to do it years and years ago, before I figured out how to read text objects in a way that fits my method.

It doesn't matter anyway, I was just curious.

Belias

you're right, we mean different things with "merge"...but obviously the result is the same let's clear it with an example:

let's say i have a,b,c and d versions...

a= old standard
b= old personalized
c= new standard
d= new personalized client (the result)

d= c + b - a

usually i work with 2 monitors: one with the toolkit comparer (a&b) and nav opened with b, on the other monitor i have "d" client. I look the differences in the first monitor and i copy/paste the differences on the second one, at the same time i control the position of controls etc. on the first monitor ("b" client) and then i replicate them on the "d" client on the fly...
I think that everyone have a completely unique method to merge objects, and maybe yours is better of mine. :-k

DenSter

Yep that's how I used to do it too, and I have cut the time I need to merge objects in half by changing my methods.

Now I do the merging right in my text compare tool (Beyond Compare), importing objects individually and resolving object conflicts as they come up, and this has proven to me, the way that I work, the fastest way to merge objects. I'm talking half the time to complete a merge process from databases that contain only unknown modifications. In databases with known add-ons the gain is even more dramatic, because it gets easier to push things through when you know what it is.

When it comes to forms and reports it gets tricky, but after a while you get to know what it all means. Most of the time I can tell how positions are affected in the text compare tool and I modify it there, and sometimes I leave the new controls out and I copy/paste manually, or I just push them into the 'D' object and manually eyeball the positions by comparing those few forms the 'oldfashioned' way. With tables it gets tricky when you have to add new fields in a range that is not included in the developer license, but that's not too difficult to resolve either.

Interesting how, to reach the same goal, different people like to do things so differently isn't it

Belias

it's the trickyness of controls properties in text objects that makes me crazy even if i can understand text objects files almost perfectly...i am worried to lose something

DenSter wrote:

Interesting how, to reach the same goal, different people like to do things so differently isn't it

exactly what i mean, and it's one of the things that makes our work somewhat "entertaining"!