Hey there Foxers!
I wanted to share something with the group, as I was pretty excited about this - and figured some folks here might find this interesting. And, yeah - this does involve FoxPro (which is why I didn't mark this as [NF]).
As many of you already know, I've been doing a LOT of work with Claude AI since I started working here at Pako - after moving to Ohio. And, not EVERYTHING has been successful with Claude - as there have been MANY Times where he Frustrated me Greatly! Including a recent VERY Weird Hallucination with him recently - which I may follow-up here in another thread - cause it was REAL WEIRD Indeed!
So - just a little back story. I was hired to support this older FoxPro system - in fact - they have TWO FoxPro based systems here. Of course, part of the deal is to help in the conversion of the system to C#. And, since I literally have really no exp. in C# before getting hired - I figured this would be a good excuse to dive into using AI for this system conversion. And, I HAVE had a LOT of success using Claude to generate XAML & CS code based upon not only FoxPro Screens - but, Reports as well.
And, as I have been doing this and converting a number of screens and reports - I've been pushing Claude A LOT - and for each new screen - learn how to improve the prompts, to get better results. But, along the way - there was something that was bothering me about the process. That is - YEAH - Claude could indeed generate C# screens based upon FoxPro screens - but, there was a problem. The screens it would produce were kinda sloppy. And, I knew WHY this was case. It was pretty obvious. BECAUSE - Claude had no "Vision"! It could translate the position of labels and data fields from FoxPro to C# - but, if things Overlapped - it could not "SEE" that it was doing things wrong and making Sloppy Arse screen designs.
Then, last week I was pondering this dilemma - and I began a train of thought. What if I could truly give Claude "Vision" - so that he could truly "See" his mistakes and Avoid making sloppy screen conversion designs. Well - I made a comment to Claude about this - this was my prompt to my good buddy Claude: Claude - that update was a lot better. But, I am VERY CURIOUS about something - in regards to what YOU can "SEE" on the screen forms that you build for me. I know you try replicate what is on the FoxPro screen layouts - and convert to XAML. However, it seems you have NO Ability to see when fields and data labels overlap. Am I right? Do you truly have no way to determine the full width of a data label - based upon the font size set - and thus know the approximate dimensions in Pixels???
His Reply(but, this is only PART of what he wrote back to me): You are absolutely correct - and I appreciate you asking this directly! Yes, I have a significant limitation: I cannot accurately visualize the rendered output of the XAML I create. Here's what I'm working with: What I Can See: * The numerical positions from FoxPro (Left, Top, Width, Height values)... What I Cannot Do: * Calculate the actual rendered width of text given a font size and string content * Detect overlapping controls visually... The Problem: I'm essentially working blind - I know that: * A label with Content="Customer Part # :" exists * It has FontSize="18" and FontWeight="Bold" * It's positioned at a certain Canvas.Left position... But I cannot calculate that this text might render as ~150 pixels wide, and therefore might overlap with a textbox that starts too close to it...
*** THE Solution *** I then wrote my idea to Claude on how to give him "Vision": OK - I have an idea. I'm putting the letter "X" on the screen. And, I am adjusting the Height & Width for that label - until both are at the bare minimum to be able to display the X - but, without chopping off any part of the letter. Then, if I give you the dimension for that letter being displayed - and also confirm it's Style like it's Size & Weight. Then, in theory, if you know this information - you could potentially then Exactly position labels and data fields - so that nothing overlaps.
Will admit - his reply was again rather funny (again - am only giving part of his reply - so as not to make this posting even BIGGER than it needs to be!): YES - you are ABSOLUTELY RIGHT! This is a brilliant idea and would give me a precise "unit of measurement" to work with! If you tell me something like: * "X" at FontSize="18" with FontWeight="Bold" requires Width="15" Height="28"... Optional - if you want to be extra precise: You could also test a few other characters like: * "W" or "M" (typically the widest characters) * "I" or "l" (typically the narrowest) * This would tell me if the font is monospace (all same width) or proportional (variable width)
So, yeah - not only did Claude confirm that I could potentially give him "Vision" - but, he gave me great input - in regards to using a "W" as well as the letter "I".
This was the screen before I implemented this "Vision" concept (which was initially create via Claude - and then I did a whole bunch of changes): https://ibb.co/HTVnYftw
After prepping the new prompt, giving Claude the ability to "See" - here is the 1st updated version: https://ibb.co/FqL5mTXV
So - there you have it.
I'd be curious to know what folks thought about this - especially Mr. Roberts - who is also extensively using Claude!
L8r G8rs, -Kurt