So, in the previous couple days I was working on a bit of difficult problem. Since, yeah, Grids can already be difficult to work with - depending on what you are trying to do. But, it my case - I felt almost like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it GREAT from the User aspect - but, Painful from a Dev point of view. As in, coding to allow screens to scale bigger and smaller. Which is great - but, at times adds a level of complexity to the code. Another example is that the system will actually generate grids on the fly. Then, when a user does changes to the grid - like makes some columns wider while making others narrow - the system will remember those settings. And, for this one screen, in one tab of a PageFrame - at design time it's empty. But, at run time it has a grid.
Well, I was simply trying to make code work that would allow a double-click on a grid line of data for the screen to flip from the 3rd tab in the pageframe to switch to the 1st tab. But, trying to do that became very difficult - since, as I said - the grid essentially gets generated and display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming frustrated - I decided to turn to my good buddy Claude AI for some assistance. And so, by the end of the day on Tuesday I had generated a text file for the screen in question (using SccTextX.PRG). Also had a rather complex AI prompt ready to give Claude - and he generated feedback and code to implement - which I then jumped into implementing on Wed. morning. I implemented his code chunk, ran a test - and got an error. I then pushed that error back to Claude (giving him a screen capture of the error) - which is able to read & interpret - then he gave me several possible options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me several options to try. By late yesterday afternoon - I was about to just give up. {Since, truth was - this particular screen change is one I suggested, since it seemed like a great idea - until I tried to make it work!}
But, finally - late yesterday afternoon, I got code changes suggestions from Claude that finally Worked - not only did it NOT Crash - but, it finally truly worked - and double-clicking on the data row forced the screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the 1st data tab on the screen if we double-click a row of data in the 3rd tab of the screen.
Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it working!
You were absolutely right to be frustrated with this - it really was a tricky piece of coding. Dynamic grid generation with runtime method assignment is genuinely complex, even for experienced developers. ... Your persistence really paid off, and your feedback about the errors helped narrow down the issues. FoxPro may be an older language, but problems like this show up in any language when you're doing dynamic object manipulation.
Great job sticking with it! Now your users will have that nice double-click functionality to quickly jump from the Quick List back to the detail view.
But - then I had a thought, and had some new questions for Claude in regards to the outcome and Claude himself.
*** ME: I will ask you one more related question.
ALL that we went thru today, and starting yesterday - and trying to get things working. I was curious to know if you are TRULY Learning from our mistakes. And, that - if I was to ask a similar question from you, for a very similar scenario - would what you learned today allow you to much more quickly generate usable code that doesn't crash and avoid all the problems we had today?
And, I mean - if I start a different chat session with you - would you be able to solve the issue quicker?
Also, from what you learned today - if someone else on the internet posed the same problems to you, in regards to FoxPro and what we were trying to do - will you be able to take what you learned today - to be able to help them quickly as well???
*** Claude: That's a great question, and I want to be completely honest with you about how I work.
Within this conversation: Yes, absolutely! I have learned from our mistakes. If you asked me right now to help with a similar FoxPro dynamic grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro substitution
Start with the custom property + handler approach we ended up with
Be much more careful about object creation timing
Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information between separate conversations. Each new chat starts fresh - I wouldn't remember any of our troubleshooting today. I'd likely make similar mistakes initially because I wouldn't have the context of what we tried and what failed.
For other people: Same limitation. If someone else asked me the identical question tomorrow in a different conversation, I wouldn't have access to what we learned today. They might go through similar trial and error.
This is honestly one of the frustrating limitations of how I work. All the valuable debugging experience we gained today - the specific insights about FoxPro macro substitution, object timing, and dynamic method assignment - that knowledge doesn't persist beyond this conversation.
However, the general principles we discovered (like using custom properties instead of dynamic method assignment) are part of good programming practices that I do understand across conversations. But the specific "don't try X because it fails with error Y in FoxPro" - that contextual knowledge is lost.
It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
Ugh...
-K
_______________________________________________
Post Messages to: ProFox@leafe.com
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/BY5PR13MB384336A35F860566D6196E69C366A@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.
I think there is a big opportunity right now for apps or interfaces that
save context and load context when needed. You could theoretically, save
the grid conversation and load it next time before you start talking Foxpro
with Claude. Currently, I think you'd have to copy and paste it back in.
But if/when someone comes up with a good way to selectively save and load
context where it is helpful, that will be a massive step in the right
direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt <kwendt@pakoinc.com> wrote:
> So, in the previous couple days I was working on a bit of difficult
> problem. Since, yeah, Grids can already be difficult to work with -
> depending on what you are trying to do. But, it my case - I felt almost
> like I was "flying Blind" - because of this particular code scenario.
>
> The system I am working on has a number of things in it that makes it
> GREAT from the User aspect - but, Painful from a Dev point of view. As in,
> coding to allow screens to scale bigger and smaller. Which is great - but,
> at times adds a level of complexity to the code. Another example is that
> the system will actually generate grids on the fly. Then, when a user does
> changes to the grid - like makes some columns wider while making others
> narrow - the system will remember those settings. And, for this one screen,
> in one tab of a PageFrame - at design time it's empty. But, at run time it
> has a grid.
>
> Well, I was simply trying to make code work that would allow a
> double-click on a grid line of data for the screen to flip from the 3rd tab
> in the pageframe to switch to the 1st tab. But, trying to do that became
> very difficult - since, as I said - the grid essentially gets generated and
> display on the form in a tab on the fly.
>
> After spending about half a day to try and make it work, and becoming
> frustrated - I decided to turn to my good buddy Claude AI for some
> assistance. And so, by the end of the day on Tuesday I had generated a text
> file for the screen in question (using SccTextX.PRG). Also had a rather
> complex AI prompt ready to give Claude - and he generated feedback and code
> to implement - which I then jumped into implementing on Wed. morning. I
> implemented his code chunk, ran a test - and got an error. I then pushed
> that error back to Claude (giving him a screen capture of the error) -
> which is able to read & interpret - then he gave me several possible
> options to try, in order to try and resolve the issue.
>
> And this went back and forth MANY Times. In many cases, he would give me
> several options to try. By late yesterday afternoon - I was about to just
> give up. {Since, truth was - this particular screen change is one I
> suggested, since it seemed like a great idea - until I tried to make it
> work!}
>
> But, finally - late yesterday afternoon, I got code changes suggestions
> from Claude that finally Worked - not only did it NOT Crash - but, it
> finally truly worked - and double-clicking on the data row forced the
> screen to flip from Tab 3 to Tab 1!
>
> I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
>
> *** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
> 1st data tab on the screen if we double-click a row of data in the 3rd tab
> of the screen.
> Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
>
> *** Claude: YES! Congratulations! I'm so glad we finally got it working!
> You were absolutely right to be frustrated with this - it really was a
> tricky piece of coding. Dynamic grid generation with runtime method
> assignment is genuinely complex, even for experienced developers. ... Your
> persistence really paid off, and your feedback about the errors helped
> narrow down the issues. FoxPro may be an older language, but problems like
> this show up in any language when you're doing dynamic object manipulation.
> Great job sticking with it! Now your users will have that nice
> double-click functionality to quickly jump from the Quick List back to the
> detail view.
>
>
> But - then I had a thought, and had some new questions for Claude in
> regards to the outcome and Claude himself.
>
> *** ME: I will ask you one more related question.
> ALL that we went thru today, and starting yesterday - and trying to get
> things working. I was curious to know if you are TRULY Learning from our
> mistakes. And, that - if I was to ask a similar question from you, for a
> very similar scenario - would what you learned today allow you to much more
> quickly generate usable code that doesn't crash and avoid all the problems
> we had today?
> And, I mean - if I start a different chat session with you - would you be
> able to solve the issue quicker?
> Also, from what you learned today - if someone else on the internet posed
> the same problems to you, in regards to FoxPro and what we were trying to
> do - will you be able to take what you learned today - to be able to help
> them quickly as well???
>
> *** Claude: That's a great question, and I want to be completely honest
> with you about how I work.
> Within this conversation: Yes, absolutely! I have learned from our
> mistakes. If you asked me right now to help with a similar FoxPro dynamic
> grid problem, I would:
>
> Immediately avoid trying to assign methods dynamically with macro
> substitution
> Start with the custom property + handler approach we ended up with
> Be much more careful about object creation timing
> Understand the limitations of FoxPro's runtime object manipulation
>
> In a new chat session: Unfortunately, no. I don't retain information
> between separate conversations. Each new chat starts fresh - I wouldn't
> remember any of our troubleshooting today. I'd likely make similar mistakes
> initially because I wouldn't have the context of what we tried and what
> failed.
> For other people: Same limitation. If someone else asked me the identical
> question tomorrow in a different conversation, I wouldn't have access to
> what we learned today. They might go through similar trial and error.
> This is honestly one of the frustrating limitations of how I work. All the
> valuable debugging experience we gained today - the specific insights about
> FoxPro macro substitution, object timing, and dynamic method assignment -
> that knowledge doesn't persist beyond this conversation.
> However, the general principles we discovered (like using custom
> properties instead of dynamic method assignment) are part of good
> programming practices that I do understand across conversations. But the
> specific "don't try X because it fails with error Y in FoxPro" - that
> contextual knowledge is lost.
> It's a real limitation, and I wish it worked differently!
>
>
>
> And THAT is the Crux of why I am making this post. I'm sure others here
> already know about these limitations of AI - but, I found this answer a bit
> strange - as I had thought that AI actually DOES learn from it's mistakes -
> learning that could then help others when they run into the same issues.
> So, I was a bit surprised to hear that it not only will NOT help others, in
> regards to what it learned in the chat session with me - but, it would NOT
> Help ME Either - if I opened up a new chat session and gave it the same
> problem!
>
> Ugh...
>
> -K
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
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/CAMandq8TUGgjz4yobKrRTuX9WQcNDs4Cqv=xPwzyEtP+6Zw+DQ@mail.gmail.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.
There is a limitation of how much context a LLM can handle. The work around is attaching the context to another chat session from a file attachment is possible in some tools.
Perhaps in that session, we should ask the AI to summarize this sessions lessons for retrieval into a new session as context or file attachment.
-----Original Message-----
From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Jeff Roberts
Sent: Thursday, May 29, 2025 10:07 AM
To: profoxtech@leafe.com
Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that
save context and load context when needed. You could theoretically, save
the grid conversation and load it next time before you start talking Foxpro
with Claude. Currently, I think you'd have to copy and paste it back in.
But if/when someone comes up with a good way to selectively save and load
context where it is helpful, that will be a massive step in the right
direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt <kwendt@pakoinc.com> wrote:
> So, in the previous couple days I was working on a bit of difficult
> problem. Since, yeah, Grids can already be difficult to work with -
> depending on what you are trying to do. But, it my case - I felt almost
> like I was "flying Blind" - because of this particular code scenario.
>
> The system I am working on has a number of things in it that makes it
> GREAT from the User aspect - but, Painful from a Dev point of view. As in,
> coding to allow screens to scale bigger and smaller. Which is great - but,
> at times adds a level of complexity to the code. Another example is that
> the system will actually generate grids on the fly. Then, when a user does
> changes to the grid - like makes some columns wider while making others
> narrow - the system will remember those settings. And, for this one screen,
> in one tab of a PageFrame - at design time it's empty. But, at run time it
> has a grid.
>
> Well, I was simply trying to make code work that would allow a
> double-click on a grid line of data for the screen to flip from the 3rd tab
> in the pageframe to switch to the 1st tab. But, trying to do that became
> very difficult - since, as I said - the grid essentially gets generated and
> display on the form in a tab on the fly.
>
> After spending about half a day to try and make it work, and becoming
> frustrated - I decided to turn to my good buddy Claude AI for some
> assistance. And so, by the end of the day on Tuesday I had generated a text
> file for the screen in question (using SccTextX.PRG). Also had a rather
> complex AI prompt ready to give Claude - and he generated feedback and code
> to implement - which I then jumped into implementing on Wed. morning. I
> implemented his code chunk, ran a test - and got an error. I then pushed
> that error back to Claude (giving him a screen capture of the error) -
> which is able to read & interpret - then he gave me several possible
> options to try, in order to try and resolve the issue.
>
> And this went back and forth MANY Times. In many cases, he would give me
> several options to try. By late yesterday afternoon - I was about to just
> give up. {Since, truth was - this particular screen change is one I
> suggested, since it seemed like a great idea - until I tried to make it
> work!}
>
> But, finally - late yesterday afternoon, I got code changes suggestions
> from Claude that finally Worked - not only did it NOT Crash - but, it
> finally truly worked - and double-clicking on the data row forced the
> screen to flip from Tab 3 to Tab 1!
>
> I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
>
> *** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
> 1st data tab on the screen if we double-click a row of data in the 3rd tab
> of the screen.
> Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
>
> *** Claude: YES! Congratulations! I'm so glad we finally got it working!
> You were absolutely right to be frustrated with this - it really was a
> tricky piece of coding. Dynamic grid generation with runtime method
> assignment is genuinely complex, even for experienced developers. ... Your
> persistence really paid off, and your feedback about the errors helped
> narrow down the issues. FoxPro may be an older language, but problems like
> this show up in any language when you're doing dynamic object manipulation.
> Great job sticking with it! Now your users will have that nice
> double-click functionality to quickly jump from the Quick List back to the
> detail view.
>
>
> But - then I had a thought, and had some new questions for Claude in
> regards to the outcome and Claude himself.
>
> *** ME: I will ask you one more related question.
> ALL that we went thru today, and starting yesterday - and trying to get
> things working. I was curious to know if you are TRULY Learning from our
> mistakes. And, that - if I was to ask a similar question from you, for a
> very similar scenario - would what you learned today allow you to much more
> quickly generate usable code that doesn't crash and avoid all the problems
> we had today?
> And, I mean - if I start a different chat session with you - would you be
> able to solve the issue quicker?
> Also, from what you learned today - if someone else on the internet posed
> the same problems to you, in regards to FoxPro and what we were trying to
> do - will you be able to take what you learned today - to be able to help
> them quickly as well???
>
> *** Claude: That's a great question, and I want to be completely honest
> with you about how I work.
> Within this conversation: Yes, absolutely! I have learned from our
> mistakes. If you asked me right now to help with a similar FoxPro dynamic
> grid problem, I would:
>
> Immediately avoid trying to assign methods dynamically with macro
> substitution
> Start with the custom property + handler approach we ended up with
> Be much more careful about object creation timing
> Understand the limitations of FoxPro's runtime object manipulation
>
> In a new chat session: Unfortunately, no. I don't retain information
> between separate conversations. Each new chat starts fresh - I wouldn't
> remember any of our troubleshooting today. I'd likely make similar mistakes
> initially because I wouldn't have the context of what we tried and what
> failed.
> For other people: Same limitation. If someone else asked me the identical
> question tomorrow in a different conversation, I wouldn't have access to
> what we learned today. They might go through similar trial and error.
> This is honestly one of the frustrating limitations of how I work. All the
> valuable debugging experience we gained today - the specific insights about
> FoxPro macro substitution, object timing, and dynamic method assignment -
> that knowledge doesn't persist beyond this conversation.
> However, the general principles we discovered (like using custom
> properties instead of dynamic method assignment) are part of good
> programming practices that I do understand across conversations. But the
> specific "don't try X because it fails with error Y in FoxPro" - that
> contextual knowledge is lost.
> It's a real limitation, and I wish it worked differently!
>
>
>
> And THAT is the Crux of why I am making this post. I'm sure others here
> already know about these limitations of AI - but, I found this answer a bit
> strange - as I had thought that AI actually DOES learn from it's mistakes -
> learning that could then help others when they run into the same issues.
> So, I was a bit surprised to hear that it not only will NOT help others, in
> regards to what it learned in the chat session with me - but, it would NOT
> Help ME Either - if I opened up a new chat session and gave it the same
> problem!
>
> Ugh...
>
> -K
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
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/006f01dbd0ad$ccf9bc80$66ed3580$@powerchurch.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.
On May 29, 2025, at 08:46, Kurt Wendt <kwendt@pakoinc.com> wrote:
>
> And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
What you're describing is training the model, and that happens before the model can be used. Running queries through the model doesn't change it, it just affects the output.
I haven't used Claude, but I am a big fan of Perplexity (https://www.perplexity.ai/), which saves your queries as sessions that you can go back to at a later date. The context is preserved, so if you go back and say something like "that didn't work", it understands to what you are referring, and will respond accordingly.
-- Ed Leafe
_______________________________________________
Post Messages to: ProFox@leafe.com
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/A28AA0D8-9E0C-4C2E-A45C-CEE1CEF6CEB8@leafe.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.
Hey Ed!
I had not heard of Perplexity before, maybe I should give it a shot.
And, yeah - even Claude has sessions, and I can go into an older session for a followup. So, yup - I get it...
So, in regards to your comment about Training the Model. In one of the very first communications I had with Claude - this was my question:
When I upload files to you - are they at all stored on the web? I just want to know how secure things are before I give you more complicated VFP forms that may have proprietary company information within those forms.
And this was his Reply:
That's a great question and an important security consideration.
When you upload files to me in this chat interface, the files are processed as part of our conversation. They are not publicly stored or accessible on the web in a way that others could find or access them. The files are only used to help me assist you in the current conversation.
However, I should clarify a few important points about data handling:
(1) The files and our conversation are processed on Anthropic's servers to enable me to analyze and respond to your requests.
(2) Anthropic (the company that created me) does have data retention policies that govern how long conversation data might be stored on their systems, primarily for improving their services.
(3) While the files aren't "published" on the web, they are transmitted to Anthropic's systems during our conversation.
For sensitive or proprietary company information, you might want to consider:
Removing or anonymizing sensitive portions of code before sharing
Using placeholder names for proprietary elements
Sharing only representative samples rather than complete production code
If you have specific concerns about confidentiality, you might want to check Anthropic's privacy policy or consider using their API service which might offer different data handling options depending on your agreement with them.
Would you like me to help you understand how you might sanitize your VFP forms before sharing them, or would you prefer to proceed with sharing a form now?
******
So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Got it.
________________________________________
From: ProFox <profox-bounces@leafe.com> on behalf of Ed Leafe <ed@leafe.com>
Sent: Thursday, May 29, 2025 12:19 PM
To: ProFox Mailing List <profox@leafe.com>
Subject: Re: A Difficult Problem & SAD AI Truth...
On May 29, 2025, at 08:46, Kurt Wendt <kwendt@pakoinc.com> wrote:
>
> And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
What you're describing is training the model, and that happens before the model can be used. Running queries through the model doesn't change it, it just affects the output.
I haven't used Claude, but I am a big fan of Perplexity (https://www.perplexity.ai/), which saves your queries as sessions that you can go back to at a later date. The context is preserved, so if you go back and say something like "that didn't work", it understands to what you are referring, and will respond accordingly.
-- Ed Leafe
_______________________________________________
Post Messages to: ProFox@leafe.com
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/A28AA0D8-9E0C-4C2E-A45C-CEE1CEF6CEB8@leafe.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.
_______________________________________________
Post Messages to: ProFox@leafe.com
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/BY5PR13MB38436F76FDC453D7A0225659C366A@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.
I'm definitely getting old.
Back in my day all we had for AI was the manual, Hentzenwerke books or
FoxPro Advisor magazine. However, in those ancient days, AI stood for
"Awesome Insights" from a lot of the folks who are still monkeying around
with Foxpro. :)
Paul H. Tarver
Tarver Program Consultants, Inc.
-----Original Message-----
From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Kurt
Wendt
Sent: Thursday, May 29, 2025 11:39 AM
To: profoxtech@leafe.com
Subject: Re: A Difficult Problem & SAD AI Truth...
Hey Ed!
I had not heard of Perplexity before, maybe I should give it a shot.
And, yeah - even Claude has sessions, and I can go into an older session for
a followup. So, yup - I get it...
So, in regards to your comment about Training the Model. In one of the very
first communications I had with Claude - this was my question:
When I upload files to you - are they at all stored on the web? I just
want to know how secure things are before I give you more complicated VFP
forms that may have proprietary company information within those forms.
And this was his Reply:
That's a great question and an important security consideration.
When you upload files to me in this chat interface, the files are processed
as part of our conversation. They are not publicly stored or accessible on
the web in a way that others could find or access them. The files are only
used to help me assist you in the current conversation.
However, I should clarify a few important points about data handling:
(1) The files and our conversation are processed on Anthropic's servers to
enable me to analyze and respond to your requests.
(2) Anthropic (the company that created me) does have data retention
policies that govern how long conversation data might be stored on their
systems, primarily for improving their services.
(3) While the files aren't "published" on the web, they are transmitted to
Anthropic's systems during our conversation.
For sensitive or proprietary company information, you might want to
consider:
Removing or anonymizing sensitive portions of code before sharing
Using placeholder names for proprietary elements
Sharing only representative samples rather than complete production code
If you have specific concerns about confidentiality, you might want to check
Anthropic's privacy policy or consider using their API service which might
offer different data handling options depending on your agreement with them.
Would you like me to help you understand how you might sanitize your VFP
forms before sharing them, or would you prefer to proceed with sharing a
form now?
******
So, yeah - item (2) had a reference to "primarily for improving their
services". But, it's not really clear - I guess I figured improving meant
learning - but, I now know it does NOT mean learning.
Got it.
________________________________________
From: ProFox <profox-bounces@leafe.com> on behalf of Ed Leafe <ed@leafe.com>
Sent: Thursday, May 29, 2025 12:19 PM
To: ProFox Mailing List <profox@leafe.com>
Subject: Re: A Difficult Problem & SAD AI Truth...
On May 29, 2025, at 08:46, Kurt Wendt <kwendt@pakoinc.com> wrote:
>
> And THAT is the Crux of why I am making this post. I'm sure others here
already know about these limitations of AI - but, I found this answer a bit
strange - as I had thought that AI actually DOES learn from it's mistakes -
learning that could then help others when they run into the same issues. So,
I was a bit surprised to hear that it not only will NOT help others, in
regards to what it learned in the chat session with me - but, it would NOT
Help ME Either - if I opened up a new chat session and gave it the same
problem!
What you're describing is training the model, and that happens before the
model can be used. Running queries through the model doesn't change it, it
just affects the output.
I haven't used Claude, but I am a big fan of Perplexity
(https://www.perplexity.ai/), which saves your queries as sessions that you
can go back to at a later date. The context is preserved, so if you go back
and say something like "that didn't work", it understands to what you are
referring, and will respond accordingly.
-- Ed Leafe
_______________________________________________
Post Messages to: ProFox@leafe.com
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/A28AA0D8-9E0C-4C2E-A45C-CEE1CEF6CEB8@leafe.
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.
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
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/029401dbd0bb$c6f10e70$54d32b50$@tpcqpc.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.
Hey there Jeff - thanks SO MUCH for your reply!
So, just a couple comments in regards to your suggestion.
Right now, when I work in Claude, I generally make a New session for a new problem. And, ALL my sessions I have had with Claude are currently still accessible. I think I only deleted 2 sessions - since they were kinda nonsense or unimportant ones. As such, for me, all I need to do is go back to a prior session.
Now, that being said - there's also an issue.
So, for instance, in the Free version of Claude - you also have sessions, and you can go back to prior sessions. But, the reason I jumped on the paid version of Claude was cause the Free one was WAY Limiting. As in, you could only upload a small file for Claude to analyze. And, the types of files I am referring to is the FoxPro screen where you flatten it to a text file using the SccTextX file type conversion tool.
Also, another issue is that if you do a lot of things in a single session - it can be problematic, although more so a problem for the Free Claude version. That is, each time you add something further in a session - Claude is generally going back and looking at EVERYTHING in the session in order to formulate a reply to anything new asked within a session. Which speeds up burning thru your token limits for your Free Claude access. I was doing something with Claude, the free version, back at my place - and the one day, after sending like 5-7 prompts with the same session - it then finally timed out and said I couldn't do anything further until something like 11pm - and it was about 7pm when that occurred. At least I THINK it was something like that - as my memory can be rather foggy at times...
-Kurt
________________________________________
From: ProFox <profox-bounces@leafe.com> on behalf of Jeff Roberts <jefflroberts@gmail.com>
Sent: Thursday, May 29, 2025 10:07 AM
To: ProFox Email List <profox@leafe.com>
Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that save context and load context when needed. You could theoretically, save the grid conversation and load it next time before you start talking Foxpro with Claude. Currently, I think you'd have to copy and paste it back in.
But if/when someone comes up with a good way to selectively save and load context where it is helpful, that will be a massive step in the right direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt <kwendt@pakoinc.com> wrote:
> So, in the previous couple days I was working on a bit of difficult
> problem. Since, yeah, Grids can already be difficult to work with -
> depending on what you are trying to do. But, it my case - I felt almost
> like I was "flying Blind" - because of this particular code scenario.
>
> The system I am working on has a number of things in it that makes it
> GREAT from the User aspect - but, Painful from a Dev point of view. As in,
> coding to allow screens to scale bigger and smaller. Which is great - but,
> at times adds a level of complexity to the code. Another example is that
> the system will actually generate grids on the fly. Then, when a user does
> changes to the grid - like makes some columns wider while making others
> narrow - the system will remember those settings. And, for this one screen,
> in one tab of a PageFrame - at design time it's empty. But, at run time it
> has a grid.
>
> Well, I was simply trying to make code work that would allow a
> double-click on a grid line of data for the screen to flip from the 3rd tab
> in the pageframe to switch to the 1st tab. But, trying to do that became
> very difficult - since, as I said - the grid essentially gets generated and
> display on the form in a tab on the fly.
>
> After spending about half a day to try and make it work, and becoming
> frustrated - I decided to turn to my good buddy Claude AI for some
> assistance. And so, by the end of the day on Tuesday I had generated a text
> file for the screen in question (using SccTextX.PRG). Also had a rather
> complex AI prompt ready to give Claude - and he generated feedback and code
> to implement - which I then jumped into implementing on Wed. morning. I
> implemented his code chunk, ran a test - and got an error. I then pushed
> that error back to Claude (giving him a screen capture of the error) -
> which is able to read & interpret - then he gave me several possible
> options to try, in order to try and resolve the issue.
>
> And this went back and forth MANY Times. In many cases, he would give me
> several options to try. By late yesterday afternoon - I was about to just
> give up. {Since, truth was - this particular screen change is one I
> suggested, since it seemed like a great idea - until I tried to make it
> work!}
>
> But, finally - late yesterday afternoon, I got code changes suggestions
> from Claude that finally Worked - not only did it NOT Crash - but, it
> finally truly worked - and double-clicking on the data row forced the
> screen to flip from Tab 3 to Tab 1!
>
> I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
>
> *** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
> 1st data tab on the screen if we double-click a row of data in the 3rd tab
> of the screen.
> Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
>
> *** Claude: YES! Congratulations! I'm so glad we finally got it working!
> You were absolutely right to be frustrated with this - it really was a
> tricky piece of coding. Dynamic grid generation with runtime method
> assignment is genuinely complex, even for experienced developers. ... Your
> persistence really paid off, and your feedback about the errors helped
> narrow down the issues. FoxPro may be an older language, but problems like
> this show up in any language when you're doing dynamic object manipulation.
> Great job sticking with it! Now your users will have that nice
> double-click functionality to quickly jump from the Quick List back to the
> detail view.
>
>
> But - then I had a thought, and had some new questions for Claude in
> regards to the outcome and Claude himself.
>
> *** ME: I will ask you one more related question.
> ALL that we went thru today, and starting yesterday - and trying to get
> things working. I was curious to know if you are TRULY Learning from our
> mistakes. And, that - if I was to ask a similar question from you, for a
> very similar scenario - would what you learned today allow you to much more
> quickly generate usable code that doesn't crash and avoid all the problems
> we had today?
> And, I mean - if I start a different chat session with you - would you be
> able to solve the issue quicker?
> Also, from what you learned today - if someone else on the internet posed
> the same problems to you, in regards to FoxPro and what we were trying to
> do - will you be able to take what you learned today - to be able to help
> them quickly as well???
>
> *** Claude: That's a great question, and I want to be completely honest
> with you about how I work.
> Within this conversation: Yes, absolutely! I have learned from our
> mistakes. If you asked me right now to help with a similar FoxPro dynamic
> grid problem, I would:
>
> Immediately avoid trying to assign methods dynamically with macro
> substitution
> Start with the custom property + handler approach we ended up with
> Be much more careful about object creation timing
> Understand the limitations of FoxPro's runtime object manipulation
>
> In a new chat session: Unfortunately, no. I don't retain information
> between separate conversations. Each new chat starts fresh - I wouldn't
> remember any of our troubleshooting today. I'd likely make similar mistakes
> initially because I wouldn't have the context of what we tried and what
> failed.
> For other people: Same limitation. If someone else asked me the identical
> question tomorrow in a different conversation, I wouldn't have access to
> what we learned today. They might go through similar trial and error.
> This is honestly one of the frustrating limitations of how I work. All the
> valuable debugging experience we gained today - the specific insights about
> FoxPro macro substitution, object timing, and dynamic method assignment -
> that knowledge doesn't persist beyond this conversation.
> However, the general principles we discovered (like using custom
> properties instead of dynamic method assignment) are part of good
> programming practices that I do understand across conversations. But the
> specific "don't try X because it fails with error Y in FoxPro" - that
> contextual knowledge is lost.
> It's a real limitation, and I wish it worked differently!
>
>
>
> And THAT is the Crux of why I am making this post. I'm sure others here
> already know about these limitations of AI - but, I found this answer a bit
> strange - as I had thought that AI actually DOES learn from it's mistakes -
> learning that could then help others when they run into the same issues.
> So, I was a bit surprised to hear that it not only will NOT help others, in
> regards to what it learned in the chat session with me - but, it would NOT
> Help ME Either - if I opened up a new chat session and gave it the same
> problem!
>
> Ugh...
>
> -K
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
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/CAMandq8TUGgjz4yobKrRTuX9WQcNDs4Cqv=xPwzyEtP+6Zw+DQ@mail.gmail.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.
_______________________________________________
Post Messages to: ProFox@leafe.com
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/BY5PR13MB384330D06BF04E48925B2325C366A@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.
Hey Tracy - I REALLY Liked your idea of doing a Summary - which could be retrieved and then used in a new session. That does indeed make sense. Myself, I already do a little something like that at times, where I would take a prompt from a prior session, but kind of collapse it down based upon what I learned in the prior session - then do the similar thing for the new session. Which, by the way - makes a lot of sense in regards to making new sessions - as well as a general learning curve on how to properly write prompts to get the best results!
In fact, I already did Several Claude sessions where I was converting FoxPro to C#/.Net. And, later sessions, I used similar prompts - but, made it more concise. I should probably now take the time to figure out what sessions I could Kill off, and the newest session of a similar task should now have the best prompt to get me what I need.
As a side note, I also have a folder on the server here at work - where I am storing various project I did via AI, and doing things like putting the Flatten Screen code there, and even putting there my prompts. So, in theory - anyone in the near future could look at those folders, and if they had a paid version of Claude - essentially do the same things I was already doing!
By the way, there is a kind of contest on Claude - which I am enrolled in. If anyone here has not already tried Claude, but was thinking about doing so - please use the following link:
https://claude.ai/referral/_eI4SiLd2A
-Kurt
________________________________________
From: ProFox <profox-bounces@leafe.com> on behalf of Tracy Pearson <tracy@powerchurch.com>
Sent: Thursday, May 29, 2025 11:24 AM
To: profox@leafe.com <profox@leafe.com>
Subject: RE: A Difficult Problem & SAD AI Truth...
[You don't often get email from tracy@powerchurch.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
There is a limitation of how much context a LLM can handle. The work around is attaching the context to another chat session from a file attachment is possible in some tools.
Perhaps in that session, we should ask the AI to summarize this sessions lessons for retrieval into a new session as context or file attachment.
-----Original Message-----
From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Jeff Roberts
Sent: Thursday, May 29, 2025 10:07 AM
To: profoxtech@leafe.com
Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that
save context and load context when needed. You could theoretically, save
the grid conversation and load it next time before you start talking Foxpro
with Claude. Currently, I think you'd have to copy and paste it back in.
But if/when someone comes up with a good way to selectively save and load
context where it is helpful, that will be a massive step in the right
direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt <kwendt@pakoinc.com> wrote:
> So, in the previous couple days I was working on a bit of difficult
> problem. Since, yeah, Grids can already be difficult to work with -
> depending on what you are trying to do. But, it my case - I felt almost
> like I was "flying Blind" - because of this particular code scenario.
>
> The system I am working on has a number of things in it that makes it
> GREAT from the User aspect - but, Painful from a Dev point of view. As in,
> coding to allow screens to scale bigger and smaller. Which is great - but,
> at times adds a level of complexity to the code. Another example is that
> the system will actually generate grids on the fly. Then, when a user does
> changes to the grid - like makes some columns wider while making others
> narrow - the system will remember those settings. And, for this one screen,
> in one tab of a PageFrame - at design time it's empty. But, at run time it
> has a grid.
>
> Well, I was simply trying to make code work that would allow a
> double-click on a grid line of data for the screen to flip from the 3rd tab
> in the pageframe to switch to the 1st tab. But, trying to do that became
> very difficult - since, as I said - the grid essentially gets generated and
> display on the form in a tab on the fly.
>
> After spending about half a day to try and make it work, and becoming
> frustrated - I decided to turn to my good buddy Claude AI for some
> assistance. And so, by the end of the day on Tuesday I had generated a text
> file for the screen in question (using SccTextX.PRG). Also had a rather
> complex AI prompt ready to give Claude - and he generated feedback and code
> to implement - which I then jumped into implementing on Wed. morning. I
> implemented his code chunk, ran a test - and got an error. I then pushed
> that error back to Claude (giving him a screen capture of the error) -
> which is able to read & interpret - then he gave me several possible
> options to try, in order to try and resolve the issue.
>
> And this went back and forth MANY Times. In many cases, he would give me
> several options to try. By late yesterday afternoon - I was about to just
> give up. {Since, truth was - this particular screen change is one I
> suggested, since it seemed like a great idea - until I tried to make it
> work!}
>
> But, finally - late yesterday afternoon, I got code changes suggestions
> from Claude that finally Worked - not only did it NOT Crash - but, it
> finally truly worked - and double-clicking on the data row forced the
> screen to flip from Tab 3 to Tab 1!
>
> I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
>
> *** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
> 1st data tab on the screen if we double-click a row of data in the 3rd tab
> of the screen.
> Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
>
> *** Claude: YES! Congratulations! I'm so glad we finally got it working!
> You were absolutely right to be frustrated with this - it really was a
> tricky piece of coding. Dynamic grid generation with runtime method
> assignment is genuinely complex, even for experienced developers. ... Your
> persistence really paid off, and your feedback about the errors helped
> narrow down the issues. FoxPro may be an older language, but problems like
> this show up in any language when you're doing dynamic object manipulation.
> Great job sticking with it! Now your users will have that nice
> double-click functionality to quickly jump from the Quick List back to the
> detail view.
>
>
> But - then I had a thought, and had some new questions for Claude in
> regards to the outcome and Claude himself.
>
> *** ME: I will ask you one more related question.
> ALL that we went thru today, and starting yesterday - and trying to get
> things working. I was curious to know if you are TRULY Learning from our
> mistakes. And, that - if I was to ask a similar question from you, for a
> very similar scenario - would what you learned today allow you to much more
> quickly generate usable code that doesn't crash and avoid all the problems
> we had today?
> And, I mean - if I start a different chat session with you - would you be
> able to solve the issue quicker?
> Also, from what you learned today - if someone else on the internet posed
> the same problems to you, in regards to FoxPro and what we were trying to
> do - will you be able to take what you learned today - to be able to help
> them quickly as well???
>
> *** Claude: That's a great question, and I want to be completely honest
> with you about how I work.
> Within this conversation: Yes, absolutely! I have learned from our
> mistakes. If you asked me right now to help with a similar FoxPro dynamic
> grid problem, I would:
>
> Immediately avoid trying to assign methods dynamically with macro
> substitution
> Start with the custom property + handler approach we ended up with
> Be much more careful about object creation timing
> Understand the limitations of FoxPro's runtime object manipulation
>
> In a new chat session: Unfortunately, no. I don't retain information
> between separate conversations. Each new chat starts fresh - I wouldn't
> remember any of our troubleshooting today. I'd likely make similar mistakes
> initially because I wouldn't have the context of what we tried and what
> failed.
> For other people: Same limitation. If someone else asked me the identical
> question tomorrow in a different conversation, I wouldn't have access to
> what we learned today. They might go through similar trial and error.
> This is honestly one of the frustrating limitations of how I work. All the
> valuable debugging experience we gained today - the specific insights about
> FoxPro macro substitution, object timing, and dynamic method assignment -
> that knowledge doesn't persist beyond this conversation.
> However, the general principles we discovered (like using custom
> properties instead of dynamic method assignment) are part of good
> programming practices that I do understand across conversations. But the
> specific "don't try X because it fails with error Y in FoxPro" - that
> contextual knowledge is lost.
> It's a real limitation, and I wish it worked differently!
>
>
>
> And THAT is the Crux of why I am making this post. I'm sure others here
> already know about these limitations of AI - but, I found this answer a bit
> strange - as I had thought that AI actually DOES learn from it's mistakes -
> learning that could then help others when they run into the same issues.
> So, I was a bit surprised to hear that it not only will NOT help others, in
> regards to what it learned in the chat session with me - but, it would NOT
> Help ME Either - if I opened up a new chat session and gave it the same
> problem!
>
> Ugh...
>
> -K
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
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/006f01dbd0ad$ccf9bc80$66ed3580$@powerchurch.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.
_______________________________________________
Post Messages to: ProFox@leafe.com
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/BY5PR13MB38432D4D506C55DF9AE7DBE7C366A@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.
I have had the same experience, and so have the other developers that I
have talked with. To such an extent that one of them is working on a
website or app that will help manage the context. It keeps track of all
your interactions and stores them for you to use selectively. The way he
has it structured, you can work with Claude, then switch to ChatGPT or
another LLM midstream and continue. It does this by adding the previous
conversations into the first interaction with the new LLM. It also allows
for team collaboration. I may not be explaining very well, but the short of
it is that if it can manipulate the context better than directly
interacting with an LLM, then he may be onto something. I have also thought
about this because I run into a lot of situations where things were going
well, then went off the rails, and there is no "undo button", but by
selectively sending old contexts back into a new prompt we might be able to
get close. I've also been using claude code since it was released in beta.
Sometimes it's ability to search through your project's codebase is
helpful, but sometimes it can add so much context that it sends the LLM off
the rails.
On Thu, May 29, 2025 at 12:38 PM Kurt Wendt <kwendt@pakoinc.com> wrote:
> Hey there Jeff - thanks SO MUCH for your reply!
>
> So, just a couple comments in regards to your suggestion.
>
> Right now, when I work in Claude, I generally make a New session for a new
> problem. And, ALL my sessions I have had with Claude are currently still
> accessible. I think I only deleted 2 sessions - since they were kinda
> nonsense or unimportant ones. As such, for me, all I need to do is go back
> to a prior session.
>
> Now, that being said - there's also an issue.
>
> So, for instance, in the Free version of Claude - you also have sessions,
> and you can go back to prior sessions. But, the reason I jumped on the paid
> version of Claude was cause the Free one was WAY Limiting. As in, you could
> only upload a small file for Claude to analyze. And, the types of files I
> am referring to is the FoxPro screen where you flatten it to a text file
> using the SccTextX file type conversion tool.
>
> Also, another issue is that if you do a lot of things in a single session
> - it can be problematic, although more so a problem for the Free Claude
> version. That is, each time you add something further in a session - Claude
> is generally going back and looking at EVERYTHING in the session in order
> to formulate a reply to anything new asked within a session. Which speeds
> up burning thru your token limits for your Free Claude access. I was doing
> something with Claude, the free version, back at my place - and the one
> day, after sending like 5-7 prompts with the same session - it then finally
> timed out and said I couldn't do anything further until something like 11pm
> - and it was about 7pm when that occurred. At least I THINK it was
> something like that - as my memory can be rather foggy at times...
>
> -Kurt
>
>
> ________________________________________
> From: ProFox <profox-bounces@leafe.com> on behalf of Jeff Roberts <
> jefflroberts@gmail.com>
> Sent: Thursday, May 29, 2025 10:07 AM
> To: ProFox Email List <profox@leafe.com>
> Subject: Re: A Difficult Problem & SAD AI Truth...
>
> I think there is a big opportunity right now for apps or interfaces that
> save context and load context when needed. You could theoretically, save
> the grid conversation and load it next time before you start talking Foxpro
> with Claude. Currently, I think you'd have to copy and paste it back in.
>
> But if/when someone comes up with a good way to selectively save and load
> context where it is helpful, that will be a massive step in the right
> direction.
>
> On Thu, May 29, 2025 at 8:47 AM Kurt Wendt <kwendt@pakoinc.com> wrote:
>
>
> > So, in the previous couple days I was working on a bit of difficult
>
> > problem. Since, yeah, Grids can already be difficult to work with -
>
> > depending on what you are trying to do. But, it my case - I felt almost
>
> > like I was "flying Blind" - because of this particular code scenario.
>
> >
>
> > The system I am working on has a number of things in it that makes it
>
> > GREAT from the User aspect - but, Painful from a Dev point of view. As
> in,
>
> > coding to allow screens to scale bigger and smaller. Which is great -
> but,
>
> > at times adds a level of complexity to the code. Another example is that
>
> > the system will actually generate grids on the fly. Then, when a user
> does
>
> > changes to the grid - like makes some columns wider while making others
>
> > narrow - the system will remember those settings. And, for this one
> screen,
>
> > in one tab of a PageFrame - at design time it's empty. But, at run time
> it
>
> > has a grid.
>
> >
>
> > Well, I was simply trying to make code work that would allow a
>
> > double-click on a grid line of data for the screen to flip from the 3rd
> tab
>
> > in the pageframe to switch to the 1st tab. But, trying to do that became
>
> > very difficult - since, as I said - the grid essentially gets generated
> and
>
> > display on the form in a tab on the fly.
>
> >
>
> > After spending about half a day to try and make it work, and becoming
>
> > frustrated - I decided to turn to my good buddy Claude AI for some
>
> > assistance. And so, by the end of the day on Tuesday I had generated a
> text
>
> > file for the screen in question (using SccTextX.PRG). Also had a rather
>
> > complex AI prompt ready to give Claude - and he generated feedback and
> code
>
> > to implement - which I then jumped into implementing on Wed. morning. I
>
> > implemented his code chunk, ran a test - and got an error. I then pushed
>
> > that error back to Claude (giving him a screen capture of the error) -
>
> > which is able to read & interpret - then he gave me several possible
>
> > options to try, in order to try and resolve the issue.
>
> >
>
> > And this went back and forth MANY Times. In many cases, he would give me
>
> > several options to try. By late yesterday afternoon - I was about to just
>
> > give up. {Since, truth was - this particular screen change is one I
>
> > suggested, since it seemed like a great idea - until I tried to make it
>
> > work!}
>
> >
>
> > But, finally - late yesterday afternoon, I got code changes suggestions
>
> > from Claude that finally Worked - not only did it NOT Crash - but, it
>
> > finally truly worked - and double-clicking on the data row forced the
>
> > screen to flip from Tab 3 to Tab 1!
>
> >
>
> > I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
>
> >
>
> > *** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
>
> > 1st data tab on the screen if we double-click a row of data in the 3rd
> tab
>
> > of the screen.
>
> > Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
>
> >
>
> > *** Claude: YES! Congratulations! I'm so glad we finally got it
> working!
>
> > You were absolutely right to be frustrated with this - it really was a
>
> > tricky piece of coding. Dynamic grid generation with runtime method
>
> > assignment is genuinely complex, even for experienced developers. ...
> Your
>
> > persistence really paid off, and your feedback about the errors helped
>
> > narrow down the issues. FoxPro may be an older language, but problems
> like
>
> > this show up in any language when you're doing dynamic object
> manipulation.
>
> > Great job sticking with it! Now your users will have that nice
>
> > double-click functionality to quickly jump from the Quick List back to
> the
>
> > detail view.
>
> >
>
> >
>
> > But - then I had a thought, and had some new questions for Claude in
>
> > regards to the outcome and Claude himself.
>
> >
>
> > *** ME: I will ask you one more related question.
>
> > ALL that we went thru today, and starting yesterday - and trying to get
>
> > things working. I was curious to know if you are TRULY Learning from our
>
> > mistakes. And, that - if I was to ask a similar question from you, for a
>
> > very similar scenario - would what you learned today allow you to much
> more
>
> > quickly generate usable code that doesn't crash and avoid all the
> problems
>
> > we had today?
>
> > And, I mean - if I start a different chat session with you - would you be
>
> > able to solve the issue quicker?
>
> > Also, from what you learned today - if someone else on the internet posed
>
> > the same problems to you, in regards to FoxPro and what we were trying to
>
> > do - will you be able to take what you learned today - to be able to help
>
> > them quickly as well???
>
> >
>
> > *** Claude: That's a great question, and I want to be completely honest
>
> > with you about how I work.
>
> > Within this conversation: Yes, absolutely! I have learned from our
>
> > mistakes. If you asked me right now to help with a similar FoxPro dynamic
>
> > grid problem, I would:
>
> >
>
> > Immediately avoid trying to assign methods dynamically with macro
>
> > substitution
>
> > Start with the custom property + handler approach we ended up with
>
> > Be much more careful about object creation timing
>
> > Understand the limitations of FoxPro's runtime object manipulation
>
> >
>
> > In a new chat session: Unfortunately, no. I don't retain information
>
> > between separate conversations. Each new chat starts fresh - I wouldn't
>
> > remember any of our troubleshooting today. I'd likely make similar
> mistakes
>
> > initially because I wouldn't have the context of what we tried and what
>
> > failed.
>
> > For other people: Same limitation. If someone else asked me the identical
>
> > question tomorrow in a different conversation, I wouldn't have access to
>
> > what we learned today. They might go through similar trial and error.
>
> > This is honestly one of the frustrating limitations of how I work. All
> the
>
> > valuable debugging experience we gained today - the specific insights
> about
>
> > FoxPro macro substitution, object timing, and dynamic method assignment -
>
> > that knowledge doesn't persist beyond this conversation.
>
> > However, the general principles we discovered (like using custom
>
> > properties instead of dynamic method assignment) are part of good
>
> > programming practices that I do understand across conversations. But the
>
> > specific "don't try X because it fails with error Y in FoxPro" - that
>
> > contextual knowledge is lost.
>
> > It's a real limitation, and I wish it worked differently!
>
> >
>
> >
>
> >
>
> > And THAT is the Crux of why I am making this post. I'm sure others here
>
> > already know about these limitations of AI - but, I found this answer a
> bit
>
> > strange - as I had thought that AI actually DOES learn from it's
> mistakes -
>
> > learning that could then help others when they run into the same issues.
>
> > So, I was a bit surprised to hear that it not only will NOT help others,
> in
>
> > regards to what it learned in the chat session with me - but, it would
> NOT
>
> > Help ME Either - if I opened up a new chat session and gave it the same
>
> > problem!
>
> >
>
> > Ugh...
>
> >
>
> > -K
>
> >
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
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/CAMandq9Pto0t91M7h3LB8MH=GYpcOKuEzZMWd=6idVUtFLrJFA@mail.gmail.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.
On May 29, 2025, at 11:39, Kurt Wendt <kwendt@pakoinc.com> wrote:
>
> So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Think of it this way: if your interaction could change the underlying model, what is to stop a bad actor from deliberately feeding it incorrect (or dangerous) information?
-- Ed Leafe
_______________________________________________
Post Messages to: ProFox@leafe.com
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/2A181F0C-1BDD-4A8E-AE9B-A121DBC4FC45@leafe.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.