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
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message:
https://leafe.com/archives/byMID/by5pr13mb38433def27bb41df93b4eda4c3...@by5pr13mb3843.namprd13.prod.outlook.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
