How'd the newbie lose his Visual Basic file?

Factual Questions
#1

OK, so it was my first time out using Visual Studio 2003 with Visual Basic (only) in it - how’d I lose the thing I was building?

Yesterday I had a designed interface and a block of code and had debugged it and created a working executable. Today I went hunting for it and I seem to have a “form” in a .vb file containing all the text, and of course the executable, but no designed interface. I thought I could save “projects” and “solutions” (which can hold multiple projects), and “forms”. Other “projects” contain a designed interface and an editor full of code that both have the same name, apparently, as forms, namely “Form1” and “Form1 [design]”. How do I save both, or how did I NOT save both yesterday? And why does the apparent function of Ctrl-S change between Save Form and Save Project depending on what part of the IDE I clicked in last?

Last, is there some kind of manual for this damn thing I’m missing? I spent some time searching and browsing the Help system without finding what “solution”, project", and “form” mean, and without finding what the File > Save function in the IDE is for.

#2

Stand very still and for heaven’s sake, don’t start a 3rd thread. I’ve alerted the mods to the duplication.

#3

Thanks.

For the record, my screen froze and the next time I started the Dope my post wasn’t there yet. Probably an electron sneeze.

So, it’s good of you to alert the mods. Do you have any information about how VB saves files, and what is a “form” that can be saved but isn’t enough to reconstruct a program?

#4

I’d like to help, but I’m baffled trying to understand what it is you say you now have or don’t have. VS03 makes it very hard to lose files & very hard to quit without saving. Now if you have hardware prone to freezing …

Here’s a primer on how it’s supposed to work …

The default location for VS03 source storage is C:\Documents and Settings<username>\My Documents\Visual Studio Projects

If you already have other projects/solutions in there you can look at them to see the structure; it’s dirt simple to figure out. If not, here’s the SD …

Considering just the simple cases, one VS project = one exe or dll. You had to have created a project to have something compilable. On disk a project is a folder named for the project (e.g. “MyProject”), which holds a file named MyProject.vbproj. That file is plain text & contains the metadata or properties from the various project setings panes, references, etc. It also contains a list of files considered as part of the project.

Your source files are also in the project folder. Each WinForm consists of 2 files, FormName.vb & FormName.resx. All your code & the majority of the form layout are stored in the .vb file. The .vb file by itself is enough to compile the app successfully, but not enough to operate the VS form designer. If you need help recreating the resx, there are techniques, but it’s kinda laborious.

Beneath the project folder will be an “obj” folder & a “bin” folder. The compiled exe (“MyProject.exe”) & config settings xml file (MyProject.exe.config) will be in bin. obj is just used for temp files during compilation .
A “solution” is a container for multiple projects. If you don’t intend to have multiple related projects, e.g. a separate class library dll used by your exe, then the solution control file is named “MyProject.sln” and is stored inside the project folder. It too is plain text & easily understandable in notepad.

For multi-project solutions, the root disk object is a folder named for the solution (e.g. “MySolution”) , containing the MySolution.sln file. That folder also contains one folder per project, each named for the projectname (e.g. “MyProject”) & each containing a corresponding named MyProject.vbproj file, source files, resource files, etc, and each containing a bin & an obj subfolder.
Pretty logical and hard to screw up. There are a couple other files in each solution or project folder I didn’t mention but for the moment we can ignore them.
(For the pedants in the crowd, yes, I just described the simple case &, yes, there are exceptions to everything I said.)
Suggest you take inventory of your disk with this folder / file layout in mind & report back on what you can find. As long as you have the .vb file we can regenerate the rest, but I can save you a couple hours of tinkering to get it right.

The more details you provide, the easier it is for us to help.

#5

When you tried getting to the designed interface the second time, did you reopen the project in Visual Studio, or did you browse to it through your file system? If you reopen either the project or solution file in VS, you should get the designer back.

I don’t have much experience with VB, but I suspect it handles forms fairly similarly to C#, so I’ll answer for that. When you design a form, Visual Studio secretly generates the source code to reproduce the form. This appears in a private method called InitializeComponent() and is surrounded with a slew of warnings telling you never to touch that code directly. So BOTH the interface you designed AND the block of code you added reside in the .vb file.

Try opening the .vb file in Notepad. You should see, along with your added code, a big honking method called ‘InitializeComponent’ containing a whole lot of statements like “Me.Button1.Location = New System.Drawing.Point(100, 100)”. That’s the code VS generated from the designer, and VS will use that code to recreate the form.

You probably didn’t have any problems forgetting to save, because Visual Studio automatically saves everything every time you compile. Plus, when you quit, it never fails to remind you of your unsaved files.

Ctrl+S should only save the file you’re currently doing work on. It won’t normally save the project or solution file unless you specifically click on it in the Solution Explorer first. But as described above, “Form1” and “Form1 [design]” are actually the same file, so saving one will save both, which can be confusing.

Visual Studio 2005 makes things a bit less confusing than 2003 because it saves the automatically generated code in a separate file called Form1.Designer.vb. VS2003 can’t do this because it requires an entire class definition to reside in a single file.

#6

Thanks! Useful!

That computer is at work and I’m home. But, from memory, I started Visual Studio and tried to Open Project by browsing for it or looking for it under Recent Projects and didn’t find it. So I closed VS and Searched Windows Explorer and found a file with the right name and a .vb extension, and double clicked it. I got VS with the code in the Editor but no Form1 [Design] window.

I also experimented around and found (IIRC) that Ctrl-S does different things depending on what panes are active, and when just the Editor pane is active Ctrl-S does Save Form. Since I thought the code text and the design form were different things I feared the design was lost and wondered why they’d make Ctrl-S save part of what you built and give no warnings. Now I don’t think that’s the problem but still think something’s wrong.

I’ll look for folders and files per above and report back. But two questions already:

In a simple project involving one graphically designed window and one text file (which I think held things like coordinates for the buttons and text boxes), do I need anything else besides the content of the text file? So, if I cut-and-paste the text into an email could the recipient recreate everything I had? and if so,

How can I recreate the window design from the text, using Visual Studio?

#7

Shoot. If you’d said that the first time you’d have saved us both a boatload of typing.

That’s normal behavior. Had you double-clicked the .sln or .vbproj fle in the same folder you’d have seen the normal UI. I believe now that no files are lost. That behavior is intended to let you open bare files without auto-opening the corresponding project so you can refer to them without disrupting the solution / project context you’re already working on.

As MBossa said, Ctrl-S means “save content of current window tab”.

For forms, the form designer window tab & the code window tab are connected, but they’re not equivalent. If you Ctrl-S on the code window tab you save just the .vb file. If you Ctrl-S on the design window tab you save the .vb file & the corresponding .resx file. This makes sense once you know that the .vb is partially generated by VS based on designer content stored in the .resx, and partly created by you keystroking in your code. So there is a one-way dependency from .resx to .vb files.

Ctrl-Shift-S means save everything. Again, unless your machine freezes or you’re in the habit of dismissing “Are you sure?” boxes without reading, it’s very hard to not save all the files when you close the solution / project or quit VS.

To deliver the program to an end user, compile it (menu “Build | Build Solution” = Ctrl-Chift-B) & send them the contents of the bin folder. By design that folder is self-contained with all needed files (the exe & any supporting files). Assuming they have the correct version of the Framework installed, all they need to do is put that folder on disk & double-click the exe. Aahh, simple installtions like they were back in the DOS days: put the files on the disk & presto.

To deliver the program as source code for another programmer to modify further using VS, it is FAR better to send them the whole solution/project folder tree. Zip it up with the folder tree preserved & send it off. They can unzip it anywhere & then double-click the .sln file in the root unzipped folder to get to work.

If you just send a programmer the .vb file they will not be able to do anything useful with it until they create a new solution/project, embed your file in it, regenerate by hand the corresponding resx, etc. That takes a good half-hour IF they’re a pro at it. Do NOT do this on purpose.
I sense a larger misunderstanding here. VB.Net is NOT an interpretted langauge. End users cannot use .vb files. Unless you wrote code to explcitly store & retrieve “(which I think held things like coordinates for the buttons and text boxes)”, there is no such file. The .resx file I’ve mentioned is akin to this, but does not actually do this. It is a compile-time file that is NOT needed at run time.

For a simple vb project as you describe, the ONLY file the end user needs (or can use) is the .exe which VS creates in the project’s bin folder. For more complex projects the .config file in there becomes mandatory. For what you’re doing it I’d bet it only holds default settings that aren’t 100% necessary for sucessful use.
MBossa FYI: we use both VB & C# in both '03 & '05 flavors in our shop. The differences in solution or project guts between the two languages is trivial. The difference between '03 & '05 is much larger, as you know.

#8

>Had you double-clicked the .sln or .vbproj fle in the same folder you’d have seen the normal UI.

No, I mean, I didn’t find any files relating to this project except for ThisProject.vb. I used Visual Studio’s browser and then Windows Explorer, and I also searched for everything saved late that day, thinking maybe I inadvertantly misnamed it. The .vb file was the only file I could find that I thought might be related to the entire adventure.

>intended to let you open bare files without auto-opening the corresponding project so you can refer to them without disrupting
Mmm, that does sound like a good feature. I appreciate that.

>unless your machine freezes or you’re in the habit of dismissing “Are you sure?” boxes without reading…
It didn’t freeze, and I was being careful and trying not to miss any clues, so I doubt I dismissed an Are you sure, but there must be some explanation. I’m just puzzling over what it is.

>I sense a larger misunderstanding here. VB.Net is NOT an interpretted langauge. End users cannot use .vb files.
Oh, I understood this already. My question about using .vb files was aimed at 1) me getting this little project back on track, and, 2) understanding how the language works.
Scanning over the .vb file, I thought maybe everything that was needed was in there. At least, from what little I’ve absorbed about win32api calls, many of the things that would be needed are there.

I’ve done the tiniest bit of windows programming before, using Forth and making calls to the API. I did get a couple simple programs to work, but it was pretty difficult. I used Petzold’s book, though that was a bit of a slog because it’s written for C programmers and I’m not very good at C. Now I’ve decided, hang the Forth, I want to be more in the mainstream, and I’ve started trying to study C++ and also acquaint myself with Visual Studio (which I had available running the VB compiler). I had two programming jobs involving Basic, so I felt somewhat familiar with it, though those were both using TRS80 computers running CPM. I’m dating myself, here - nobody else does…

#9

>The .vb file was the only file I could find…
AND it was exactly where I expected everything to be, reinforcing the idea that things were just flat out missing.

>from what little I’ve absorbed about win32api calls…
Not to forget that in VS it might also be using the CLR. There’s enough new to remember here, I hope you’ll forgive me, but I’d have to go back and look things up to figure out if I expect what I was doing to be making its own calls to win32, or using the CLR, or for that matter whether other things are handling the Windows part - WFC? I’ve seen all these things here and there but can’t quite hold it all at once without all the books open.

Hey, maybe you’d help me get two other ideas straight?

  1. How is the .NET framework and the CLR different in principle from having .dll’s around? Don’t both amount to dynamically loading and linking to sections of object code from the disk at runtime? What is new about .NET relative to dlls?

  2. Many references seem to say that C++ is for writing native or “unmanaged” Windows applications whereas C# is for writing applications managed by .NET. But it looks to me like you can compile either language for either environment. So it looks to me like C++ versus C# is a difference in front end, while un- versus managed is a difference in the back end, of the compiler. What am I missing?

Thanks greatly! These kinds of questions are difficult to look up, but hugely worthwhile to me. I really appreciate it!

#10

EDIT: This is in response to your first note. Second response is in process …
OK. I get the situation.

Strictly speaking, the .vb is all you need to compile your app using the commandline compiler. All the rest of the folder structure & files are about keeping stuff organized & making the Visual Studio IDE do its magic.
Just to be clear, if somehow all the files are gone except the .vb file we can re-create the rest. All but the .resx are trivial. The resx takes some work. Let us know Monday what you’ve got & we’ll write up a .resx how-to if needed.

ref your studying …

The programming world has gotten real specialized, and vastly huger than it was in the CP/M days when you started out (& the mainframe days when I started out).

If you want to learn something mainstream, I suggest picking VB.NET or C#.NET if you want to go Microsoft. Don’t try to mix C or C++ with C# or try to mix .NET with non-.NET programming. Those are two very different worlds that are each gigantic with very little overlap. Tackling both at once is a recipe for confusion.

I’m not compentent to offer advice on non-MSFT environments if you’d like to try one. But there is no shortage of folks here who could offer sound advice.

Bear in mind that much programming now is done over the web, where you’re programming a server in one language to send html & (usually) javascript to execute on a browser. That’s quite different from the traditional [my program runs on one machine] dev model you’re used to.

In fact there are legions of programmers out there now who can’t write code for a console or windows app, but can make the web server/browser combo sing & dance. If/when you ask for advice, make sure to specify which envirnment you’re talking about or the unstated assumptions will get in the way.

#11

This is critical to get straight. A standard .NET program NEVER touches the Win32api. As far as you’re concerned, Win32 does not exist. Your .NET app calls into various .NET DLLs that perform their magic. Whether they call Win32 or not is not your problem. There is no direct mapping from Win32 to the .NET APIs, and the sooner yuo forget every Win32 factoid yuo know, and lose all your Win32 books, the happier you’ll be.

(I simplify a bit, but it’s close to the truth).

Ultimately, .NET (the CLR & CLI) is a bunch of Windows dlls. The point of them is they are a new API design that is more logical, more consistent and much easier to use than the old ones. So as a dev, you can now deal with a much better API to the OS & ultimately the hardware.

It is also written to be very OS & hardware agnostic, so at least in principal your code can be recompiled to a mainframe runing Linux with no source-level changes.

Finally, the CLR is all about sandboxing your code so it can’t damage the OS, can’t easily be hacked, can support much more sophisticated securoty models, etc. The CLR/CLI also supports very different & more robust lifecycle management, versioning, etc. Many of the things that make classic thkc-client software a bitch to write, deploy, and maintain are dealt with inthe Framework so yuo don’t have to.

“Managed” is equivalent to “.NET”. “Unmanaged” is equivalent to everything else, ie traditional Wintel programming.

VB.NET, C#.NET, J#.NET are all .NET languages. You write them using the .NET API & compile them using Visual Studio. The output is .exes & .dlls which look like conventional files to you & I & the Windows file system, but which are utterly different inside from traditional exes/dlls. When they execute, it is under the control of the CLR / CLI / Framework (defined next).

C++ is an unmanaged language. The only thing it has in common with the languiages above is that the Visual Studio IDE knows how to edit C++ text files & hot to run its compiler. That produces traditional exe/dll which are run directly by Windows on the hardware.

The two worlds share nothing except the overgrown text eidtor that is VS.

(It would be nice if things really stayed that clear, but naturally there are exceptions. A C++ dev can incorporate .NET where convenient, and there are ways for a C# app to sneak into unmanagened world for a few lines. beyond that, there are explicit tools available to bridge the gap, commonly called Interop to let .Net call into unmanaged, and RCW/CCW to permit unmanaged to call into .NET. For now, DON’T GO THERE. Bafflement ensues.)
CLR / CLI / Framework: More or less synonymous terms for the .NET product itself, a run time infrastructure that makes alll the magic possible. I need to dash, so I’m gonna cut this short. but think of it simply as a sandbox inside which your programs run which provides a better set of hardware & a better OS than the real one. It is NOT like the JVM, and your code is running raw instructions on the raw harware. The CLR just provides a better OS, better memory protection, better securoty, etc. Better dev handholding at every step of the way.

#12

Wow, LSLGuy, thanks!

I found my files and my project, sort of, and have no recovery problem now. But this gives me a new question about saving etc as I still don’t understand what I should be doing.

I started with an earlier Project that calculated forces and started to rewrite parts of it to calculate torques instead. Since I wanted to be working on a whole new thing that just has some algorithm content based on the old one, I tried to use “Save As” to create a new Project. Unaware it mattered, I had the Form1.vb tab highlighted, and “Save As” wrote new .vb AND .resx files in the “TorqueVersion” folder I created, but now I understand it didn’t start a new project. Turns out I just changed the old “Force” project, which I guess is unrecoverable (and that’s OK).

New question: what should I have done to spawn a new Project based on the old one? I would have thought I should have the solution highlighted in Solution Explorer and click Save As. This creates .sln and .suo files in the new TorqueVersion folder I chose. With VS closed I can doubleclick that new .sln and VS opens, and then by clicking on things in Solution Explorer I can see my old code, and I can debug it and get a new executable - but none of this new work appears in the TorqueVersion folder! It all goes into the first folder. Highlighting the project in Solution Explorer doesn’t let me save as to any location outside the first folder, either. How do I spawn a whole new Solution or Project in a new location? And, yes, one Project per Solution sounds fine for now.

>C++ is an unmanaged language.
OK, this sounds important. I asked because it doesn’t look this way to me, to wit: I downloaded the free Visual C++ 2005 Express Edition, and File > New Project offers me a decision tree:

-Visual C++
|-CLR
|-Win32
|-General

This looks to me like I could choose a managed (first choice) or unmanaged (second choice) endpoint for what starts as C++ code. The book “Ivor Horton’s Beginning Visual C++ 2005” seems to confirm this: “You have tremendous flexibility in the types of applications and program components that you can develop with Visual C++ 2005. As noted earlier in this chapter, you have two basic options for Windows applications: you can write code that executes with the CLR, and you can also write code that compiles directly to machine code and thus executes natively.” All this made me think C++ works fine either way. You say “A C++ dev can incorporate .NET where convenient”. Is C++ a language that works fine either way, or is it an unmanaged language that can sort of pretend sometimes, or an unmanaged language that can be horribly deformed to act managed if you really insist, or what?

>VB.NET, C#.NET, J#.NET are all .NET languages.
>a run time infrastructure that makes all the magic possible
Oh! I now see VC#2005 doesn’t offer to start unmanaged code projects. Does this mean that if I use VB or C#, some people I give .exe’s to won’t be able to run them because they don’t have that run time infrastructure?
Stepping back, let me beg your advice about my goal: I’m a scientist who programs occasionally and want to stay that way. But I want to be able to create and give custom technical software to anybody who has a PC and is accustomed to Windows applications, for whom a console app is an unfamiliar and half-done oddity some won’t even try. Practically, I’ve been limited to giving code that runs in some special environment, like “SAS” for statistical analysis or “FlexPDE” for finite element problems, and I couldn’t give software tools to people that aren’t experienced license users of those complicated and expensive packages. That’s what I want to change! I want to get good at solving technical problems outside of those environments, and have a modest but useful practical ability to add simple Windows interfaces. I see scientific computing forums and numerical and graphing libraries focus more on C++ than anything else, and Visual Studio seems very practical for creating interfaces. So I’m barking up the Visual Studio and C++ trees, and wondering if I should focus on C# instead, or happily go after them all, or dismiss the whole idea as too ambitious. Today I think it’s reasonable to try, and that getting more grounded in the C family would serve me well in the future. What do you think?

Sorry to ask so many questions! I’ll be grateful for whatever you can give me!

#13

Excellent & insightful questions.

This’ll have to wait until Tues eve, but I will get to it.

#14

Well, It’s Wed night, not Tues, but better late than never …
Q: Spawn new project/solution from old …

A: Not a directly supported concept. What I would do is simply create a brand new solution/project for my new effort. Then use Windows disk Explorer to copy the source files I wanted from one project to another. Do NOT try to copy the entire solution/project folder tree in hopes of cloning it; that will leave a mystifying mess as there are some internal linkages in the control files that will be messed up in the new/clone project.

A helpful thing to do is click the “show all files” icon in the little toolbar at the top of the Solution Explorer pane in VS. That way you see everything in the project physical folder & it also clearly shows the hidden dependent files that reside behind some content files, e.g. the .resx file connected to a WinForm.

(A single VS instance can open exactly one Solution at a time. It can open all projects & files within that Solution without limitation. If you need to see two Solutions simultaneously, open two instances of VS. I’ve had a dozen open at once; it still works fine, if a little slowly.)

With “show all files” on, you can see which files you need to copy from the source project folder to the target project folder. i.e once you indentify a file in Solution Explorer, also copy any child files. Once copied, VS Solution Explorer will show the new files within the target project. They’ll appear with a sorta-disabled looking icon. Right click & choose “Include in Project” to add them into the project. At that point the icon changes to normal & they become designable & buildable.

Aside: Files in the project can be excluded at any time by a similar right-click process. This can be handy for alternate versions, work in process, etc., that you want to temporarily exclude from building but don’t want to delete or misplace the disk file.

Related GOTCHA: “Save As” does NOT work like it does in other apps. Typically “Save As” means “Leave the current disk file version alone & save the in-RAM as-edited version under a new name.” That is NOT what it means in VS.

In VS it means “Destroy the file with the old name, save the in-RAM version under the new name, fix-up any references in any hidden component files connected to the saved-as file (.e.g. resx), and finally fix up about 98% of the other intra-project references to the old file to point to the new file”. In other words, it’s effectively Rename on steroids. And yes, it’s confusing as Hell the first time you encounter that unexpected behavior. But it makes operational sense.

Bottom line: If you want to duplicate a file to fork it into two versions or into a new project, use copy/paste in VS or WinExplorer, not VS “Save As”.
Q: C++ …

A: I am NOT a good source for C++ advice. In early .NET, C++ was all but verboten. I understand now that there is a managed flavor of it, but AFAIK, the emphasis is still on using C++ for non-managed apps with dips into managed world where needed.

My personal take (not having ever been a C++ guru) is that there’s no reason to use C++ for mainline .NET-centric dev. C# offers a similar sytax & style familiarity without the “++” nastiness. But I freely admit this is based on reading & hearsay, not practical experience. Your quote would seem to indicate C++ has migrated even closer to .NET than I realized.
Q: Runtime infrastructure & dependency …

A: If you create a C# or VB exe, or one in C++ that uses any managed features or calls, then that exe is 100% dependent on the .NET Framework. The exe will not run at all unless the Framework of the appropriate version is installed on the user’s machine.

The good news is that XP Pro Service pack 2 included the Framework v2.0, which will also run v1.1 (ie VS2003) apps. Vista includes the latest Framework version, 3.0. So many of your potential users will have the Framework installed even if they don’t realize it.

If a user w/o the Framework tries to execute your exe the loader stub will automatically invite them to the relevant MS website to download & install the needed version. For v1.1 the download is ~23MB and has zero user decisions. In other words, not a big deal for a even a clueless user with a broadband connection. Like any install, they do need administrator access to the box.

Framework versions are strictly upwards compatible, so anyone with 2.0 or 3.0 will be able to use your 1.1 stuff just fine.
Q: Meta-goals …

A: You have a sound plan & I think what you want is readily do-able.

For building straightforward Windows GUI apps, you can’t beat VB.NET / C#.NET for results/effort ratio. It isn’t hard to build good UI & the algorithmic stuff is straightforward as well. .NET incorporates very easy classes for every core data structure you might need as well as easy IO, etc. For your background, C# makes more sense than VB, so I’ll drop the refs to VB hereafter.

C# can leverage almost any existing COM library, so if you need to use somebody’s special purpose library for Finite Element Analysis or whatever, that ought to be readily doable. C++ isn’t really necessary. If you have a COM interface need, best to get comfortable with .NET in general first as COM interfacing is automatic for the simple cases, but you need to know enough to recognize the non-simple cases.

Aside: the current version of Visual Studio is 2005, which builds code for Framework v2.0. There have been many, many advances over VS2003/Framework v1.1, particularly in the built-in data structures. Since VS05 Express is free, I suggest you move to that immediately unless you have a reason to stick w/ VS03. The IDE is very similar & the code ports trivially with a built-in wizard, so your efforts to date are not wasted. The replacement for VS05 (VS07/“Orcas”) will release in about 4-6 months, so jumping to VS05 is hardly bleeding edge.

I wish you well in your explorations. This forum has several .NET pros on it and is a good resource for the high-level questions you’ve asked. For nitty gritty coding there are better places to ask Q’s.

#15

>A: Not a directly supported concept. What I would do is…
This makes perfect sense. I am going to explore what you explained next.

>My personal take (not having ever been a C++ guru) is that there’s no reason to use C++ for mainline .NET-centric dev. C# offers…
I also want to explore this. I heard something similar from a fellow downstairs who does no scientific work but lots of development of nontechnical things. It’s a good lead.
>A: You have a sound plan & I think what you want is readily do-able. For building straightforward Windows GUI apps, you can’t beat VB.NET / C#.NET for results/effort ratio…
Your opinion is immensely encouraging. In the beginning of an effort like this it’s all to easy to miss some early clue you don’t know to look for and waste much effort. For example, when I made the jump from Windows 3.11 to Unix, by myself, I struggled for a couple of months making a Sun workstation do what I wanted it to do BEFORE I inadvertantly discovered the man pages. It’s not like there was a sticker on the outside saying “the instructions are here”. If there’d been a WWW and a SDMB that year, you might have been the one to tell me.
Wow. Your comments are just immensely valuable and I can hardly express my appreciation. Ah… can I just wish you well in your explorations, too?

Thanks!!!