S1ack

>My concern are the gas trains meeting ASME codes for the interlocks to work properly.* Doubtful, OEM is Japan based. It's not a plant, it's a plasma etching machine. Etches semiconductor / optical wafers used in fiber optic comms or so I am told. > This image is marked up with where to click at to bring the color property editor. OK, not sure what to do with that information. This is from my NT VM... >Also a text box shows effect of copying a shape control and pasting it into a text editor. OK, also not sure what to do with that.

So you are sure about this. I have looked as the source - bit my lack of experience is not helping. I can do that in Ignition with scripting but it's more involved that the other option. I sorta see it if I follow the 'FBit' which I take to be the Formbits i.e. the bits passed form the form (as seen in the object inspector) to the control source as Bits0-8. But I probably have that terminology mutilated somewhat. Here it looks like the individual bits, if set are then setting a value to the equivalent integer of the bit positition. If I follow FColor with the same assumption that it's the colors as seen in the object inspector.... Towards the bottom is what looks where the colors are set... But I really have no clue how the Fbits are tied to the Fcolor. There seem to be myriad uses of 'value' in between the two, But like I said. I'm a noob. I attached the source .pas. DspItem.pas

More general questions... Is it obvious to veteran Delphi users that this TDspItem is using the Bit1-BitAlarm properties to select a color for the button/panel? Because that's what I'd assume looking at it. Is it a one-for-one bit-to-color mapping? or are the bits enumerated to an int to select the color. Here 4 bits could do 16 colors, but there are only 9 colors for the control. Here 2 bits and 4 colors which implies an integer selects the color. Or is that a stupid question and the controls are different so the action could be different. One would have to look at the source. The most likely answer. I suppose. Unfortunately 1 semester of Pascal in 1989 - and I am not sure I am up to that task. I've looked at it and I get the feeling that the bits are resolved to an integer and that sets the color. I could post the source, unless that is against the rules.

So, I went to the customer yesterday and had success. On my VM I can now open forms without error, and most importantly see the PLC addresses within the object inspector. Which was my goal. blah, blah, blah... They had setup the Windows NT machine with a network share to an XP machine so I could move files off on as needed. In my limited knowledge hind sight, the issue, as many of you tried to point out was my VM installation did not have packages / components installed. I managed to do that yesterday. If somewhat clumsily stumbling into a positive result. The machine's OEM had apparently developed standard components in Delphi. Where the project files were all contained within folder \NLD6000 (the machine model) there was another folder \UlvacStd that had a \cmp subfolder filled with .pas, and .dcu files. I had this already, but copied it again to the VM, initially I naively tried to just add the path to libs tab under menu Tools | Environment Options . Did not work. Looking at the Windows NT machine the components were inserted into dclusr50. On the VM I tried to insert them all - selected all *.dcu - and install failed. Tried again selected all *.pas - install failed but looked much better than before with hints, warnings, and errors being reported. So I deleted all components that it errored on, and continued trying to install. Did not work. Brute force back door clutching at straws: I removed C:\Program Files\Delphi5 from the VM, and replaced it with the same from the Windows NT machine. Bad Idea. Replaced original Delphi5 folder, then copied the Windows NT \Delphi5 onto it selecting to overwrite all. Then when Delphi next launched (complaining about unlicensed modules), I selected ONLY the (4) .pas files that corresponded to the (4) class names the form I originally tried to open complained about. There was a logner list than (4) things in a tree structure dialog, which I took as it bringing along dependancies? In any case, this time it all installed without error, and boom I had a new palette. Hot damn tamale. Thank you very much but that will not be necessary, I have .iso images of Compolet, and FINS gateway CDs that the customer had.

Thank you all for the replies. I realize it's long shot. And I'm starting to believe it's not worth the trouble vs my other option of reverse engineering from the PLC. Only problem with that is comments in the PLC (they did not use symbols/names of the addresses) may not have a high correlation with the names in Delphi / on the screens. Yes, PLC is/was a C200PC-ISA13-DRM SYSMAC: Customer supposedly has all the original disks. This is their routine when they rebuild the WinNT... I asked if I could image those install disks and they are going to oblige. If not having the board causes problems with rendering the HMI or opening forms (assuming I get the missing classes issue fixed) well then I'm out of luck.

Interesting. OK. Lots of hits... Does the above hits 'make it so'? i.e. your 'dropped on the form' is what happened. I am clueless about the package *dpks means I should do. At first I thought you were implying that the classes I'm looking for are there inside the form. But that seems strange. Now I'm thinking it's just another means of adding it to the project - drag and dropped onto the form when under construction. Which assumes I'd still need the source of the class(es) Delphi cannot find.

Thanks for the reply. Did that. Finds many - declarations or definitions (like I said I'm a noob). No Library path that I could see. I added the root folder of the project to 'search path' hoping it's recursive. Saved and re-opened the header form. No luck. I'll be going to the customer tomorrow to fiddle with an NT system they have on life support as a backup HMI. Hopefully I'll observe the project in a more functioning manner than the the VM I am trying to create. I asked the customer to search his hard drive for the SYSMAC item, and it hit on C:\ProgramFiles\Borland\Delphi5\Imports - I'll be looking at that.

TL;DR OP has never used Delphi before. Been tasked with replacing circa 2000 Delphi 5 based HMI with an Ignition based system. So, a mega lack of knowledge by the OP For Nostalgia...? This HMI talks to an Omron PLC (programmable logic controller), which is on an ISA card in the WinNT machine, via a compiled C library *I think*. Installing Delphi 5 on a fresh WinNT VM to examine forms etc.. I have Delphi throwing error dialogs upon opening what is the 'header' form, complaining about classes not found.... Classes not found: TParts, TDspItem, TDspChg, TTxEdit Are these common things from back in the day? or Obscure? I guess that's the immediate question - can I get this project to load forms without throwing errors? Googling is not providing results. Or the signal to noise is low. Thought I'd ask here - if it appear to be what I think it is - an active forum for people who use Delphi or what Delphi has become in 2023. I ran through the Delphi 5 install again thinking I'd select custom install and perhaps get lucky with some option to install what ever it is that makes Delph aware of those classes it's not. That was a bust - but there were some errors during the install about not being able to open install logs. And another about how I Why am I doing this? Biggest issue: Attempting to get a complete picture of all the data to/from the HMI and the PLC . Including access information like what is read only from the HMI and what is read/write. Frankly I do not know if this is a worthwhile endeavor to figure out the mapping. But my other option is a heavy slog reverse engineering from the PLC side of things (learning curves attached with that, whereas the PLC logic was a few click conversion to a modern piece of hardware). I've been provided with all of the Delphi files by the customer, and have looked through them extensively, looking for definitive mapping of all the PLC memory areas that the HMI uses. This leads me to believe it's several hundred words in the 'DM' area. The MainSrc.pas file implies that the HMI calls functions to read write from an included library. I've reached out to Omron about doumentation for this TSysmac_C thing but they have not been helpful. Occasionally there are ASCII files within sub folders (of the root folder that contains the Delphi project files) that do list PLC memory locations but my fear is that it's not complete. And it also suggest some multiplexing going on. Frequently these files do not have column names, so I though poking arond in Delphi 5 miht fill in those blanks. Lastly, at least I can color check things and make the new HMI look and feel like the old - (Which was requested).