Discussion forum for the BasicX family of microcontroller chips.
|
Can someone at NetMedia confirm something for me? The Compiler/Downloader and Editor, What language is it written in? The ActiveX Control objects (OCXs) seem to point to VB, but can someone confirm that? I think I'm onto something here with that v1.48 directory-trashing bug I posted previously. .db. [Non-text portions of this message have been removed] |
|
|
|
Everything is written in VB. Jack --- In basicx@y..., "Dan Bielecki" <Dan.Bielecki@A...> wrote: > Can someone at NetMedia confirm something for me? > The Compiler/Downloader and Editor, What language is it written in? > The ActiveX Control objects (OCXs) seem to point to VB, but can someone > confirm that? > > I think I'm onto something here with that v1.48 directory-trashing bug I > posted previously. > > .db. > > [Non-text portions of this message have been removed] |
|
|
|
Jack, Thank you for the response. I appreciate it. That is what I and others thought. The ActiveX controls are a give-away. Here is what I have uncovered so far in regards to the issue of directory corruption. Please bare with it's length. I develop under a main directory named @Development. Under it, there are assorted subfolders named JAVA, HTML, Visual Basic, BasicX, ect...depending on the language I am developing under at the time....Then under those, the assorted projects and versions of the projects. This can lead to extensive path names as far as length of an internal string goes. I also have a directory name @Protoware (including the assorted language sub-folders, version etc...) that is at the same level of of the @Development folder. The @Protoware folder is where I write and experiment with different modules and programs that aren't really "under development" per say. They are more or less prototyping software modules that may or may not ever make it into actual development. What I have found since the upgrade to v1.48 is that both of these folders can become corrupted over prolonged use of BasicX dev system under the following conditions: 1) The original BasicX installation of the dev system is NOT directly a child or parent folder under the @Development or @Protoware folders. The folders contain only source and object code for different projects under development. The BasicX dev system is installed under the Program Files folder along the same lines that most programs are. The matter of the original or a modified installation path has no effect on eliminating the problem. BasicX is just separate from actual source members. 2) Since development is taking place outside of the BasicX installation folder, one must click up-and-out of the installation folder using the dialogue boxes... and then down into the desired folder. This dialog box acts pretty standard so I dont think its really the culprit. One can never be too sure though. 3) The original installation default path settings are left alone. The dialog box path setting is unchanged from the initial installation of v1.48. It is pointing to the default installation path settings under BasicX. Since I may be developing different projects at different times, making any type of changes to this setting really has no effect to me. I almost always have to click up-and-out and point to what I want to work on at the time. This may be an @Development on a CDRW or the @Development on my C drive. These days, almost always to CDRWs so my projects are portable and recoverable in the event of a hard disk crash. In this case, since a CD directory structure is different then a disk, and its harder to corrupt it, I receive a windows dialog box informing of an internal error and BasicX ends abnormally sometimes when saving with the F2 key.. 4) If no external interaction is done outside of BasicX, the directory structure(s) will remain intact. Interaction being, no requests to Windows Explorer or editing of a different BasicX source member in Notepad for example. If I never leave the dev system for any reason, I'm fine. 5) If interaction is performed, such as editing a BasicX source in the dev system, but also reviewing, browsing or editing of a different source member under a different or same master folder (@Development or @Protoware) the directory can become unstable, unusable and corrupted once the BasicX system is eventually closed and the job is ends. 6) My entire development PC is up-to-date. This include Win2000 Pro service packs, VB 6.0 service packs, IBM Aptiva firmware and BIOS updates. Everything. The Aptiva series are very stable platforms and are very automated in regards to firmware and BIOS updates. So is Windows 2000 Pro. From an system operational point of view, Im current and on the cutting edge of technology. Based on all this...here's what Im think'n.... The @ character is a valid as far as naming conventions go for files and folders. I've use it for years so certain folders appear at the top of my directory listings...like in Windows Explorer, so I dont always have to go searching and scrolling for my development folders. It appears before the letters A-Z in ASCII sorting. I also know, being a developer myself , that @ is a special string formatting character in VB when writing string data. So Im thinking that maybe the writes that occur in the BasicX system to the directory structures are not being performed using standard routines or DLLs and are somehow interpreting the @ symbol in the folder names as that of a formatting character instead of part of the actual folder name. I dont feel VB itself is directly a factor since a lot of code is written in VB these days and there has never been issues with the @ symbol before in other packages installed on my system. My own VB code also does not produce this effect. The directories exist at the time....so that would be considered an update, not a create, and if the @ symbol is in fact being evaluated somehow in the BasicX logic as a formatter, then after evaluation, the path name would be minus the @ symbol, shifted and formatted differently then the actual name of the directory entry to update. That would be a problem. Since the source can also be auto-saved at times this would mean that the update is taking place to the file and disk sectors repeatedly in different folders, at different times, (such as to the temp one under the dev system), but upon program closure of the dev system the "final" beginning and ending sectors of the actual data, are updated and closed, the directory entry is then updated, or removed and created, depending on NetMedia programming standards. This has to involve at least two strings. One for the temp, and one for the actual path. There could be more, but for the sake of this..lets say just two are involved. these strings would have to be swapped in and out over time as the saves are happening...more so if the auto-save is active. Every 10 minutes (default) the temp path would be swapping into a string, executed upon and swapped out....Same goes for when F2 is pressed. There has to be some problem with this area since the folders become corrupted repeatedly by using BasicX. I have used some of my other language tools on source that exist under the @Development and @ Protoware folders, (the JAVA tools , HTML tools, VB 6.0, straight Text, and some plain old QuickBasic.), attempting the same steps and none of the others result in the folder(s) becoming unusable. Im almost positive that its the BasicX dev system writing inappropriate directory entries at some point either during an auto save or at some point of the BasicX system in its overall processing. Please have the matter reviewed....and I hope all this (lengthy as it is) helps in the evaluation and review of the v1.48 source code ! and thx again for getting back to me. .db. -----Original Message----- From: [mailto:] Sent: Tuesday, April 10, 2001 07:25 AM To: Subject: [BasicX] Re: * NetMedia * Can you confirm? Everything is written in VB. Jack --- In basicx@y..., "Dan Bielecki" <Dan.Bielecki@A...> wrote: > Can someone at NetMedia confirm something for me? > The Compiler/Downloader and Editor, What language is it written in? > The ActiveX Control objects (OCXs) seem to point to VB, but can someone > confirm that? > > I think I'm onto something here with that v1.48 directory-trashing bug I > posted previously. > > .db. > > [Non-text portions of this message have been removed] Yahoo! Groups Sponsor >> Enter Business Search Term above Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed] |