Text length problem

Hey guys, I have a problem I need some advice on.

I know the max length for a textbox is ~65k characters. And to be able to use more, to use a RichTextBox.
When I switch to a RTB, it works beautifully, but my program is a stand-alone .exe app. No installer, no support files.

Well here is my problem.
Using a standard textbox in the program, when compiled, has run on every computer I've tried it on and all the testers computers without having to worry about support files or anything, works perfectly as long as the text length doesn't go past 65k. But Now that I am needing to use the RTB for larger inputs, the first computer I tried it on threw up the error: "Component ‘RICHTX32.OCX’ or one of its dependencies not correctly registered: a file is missing or invalid".
Which I was afraid of.

So, without forcing me to turn this into an installer with that .ocx file included, does anybody have a solution for how to deal with extra text length and not requiring support files to handle?

My suggestion would be to use the installer. If you run your app on Win98 or ealier you might run into a problem if the user does not have VB6 runtime files installed, which do not come with the OS by default like they do with XP and later versions of Windows.

I've got to find a way to keep this as a stand-alone if humanly possible. It will kinda defeat the purpose if I have to force an installation just to have 1 .ocx file included.

The program won't be supported on anything older than Win2000 or maybe even XP.

Just tried to run it on an XP Pro machine and that is where the error came from. It ran just fine on that machine prior to using the RTB too.

I'm not sure if this is possible, someone else will have to fill in as it's over my head. But it may work if you pack the ocx in a resource file than load and use it from the resource. (Nobody laugh if this is a stupid idea!) :)

I'm not laughing, as I need a genuine solution.

Don't even know how to do what you just said either. ;)

I remember a couple of years back i was working on skins and i remember something to do with API or something that will not need any additional files on exe. I think it was an open source example to download on http://www.freevbcode.com

its been 2 years so i dnt know exactly where is it but that site is great for examples and tools

My 2 cents

Yeah, I've seen some posts on some forums asking similar questions and they all point to info about creating it using API's.
The problem is, all the links provided are dead and doing searches on www.freevbcode.com and www.planet-source-code.com/vb all yield no helpful results.

I just knew this would be the least complicated part of the whole program, but apparently not. lol

The best approach really is to create a setup package of some sort. I can't imagine why hacking around with things like dumping a resource to a file and trying to register it make sense. That has a number of hazards of its own.

The PDW is pretty trivial to use if you have just the one external dependency.


If you're truly desperate and you don't need much functionality out of the RTB, you could always try using a naked RichEdit control. I've attached a small demo. Doing more with it requires more work of course.

For this program, I need to avoid an installer if at all possible. That means not using any dependency files. So far, I've found ways to code every aspect of the program to work perfectly as a stand-alone app. So, no resource files, no dependecies to have to try and register. The program will be able to run from the desktop, usb drives and probably not as an Admin account.

All I need is a text field within the program to be able to hold more than a textbox can, or a suggestion as to how to accomplish that. I don't have a problem using 3rd party to handle that, but if the requirement is to include other dependency files, I'll have to pass unless there is just no other way.

That PSC demo you linked to is reading large text files. My program doesn't have anything to do with text files. It's the TextBox that I need help with.

The attached project you have there seems to look functional.
The only thing I need the RTB for is text length. No formatting or anything. Just length of text. If I could cheat with a standard textbox I would.

I will tinker with what you posted and see if i can get it to look right within my program and work properly with what i'm doing. Thank You

One possible way is to move your text to a scratchpad file on disk. Then use your textbox as a window into the file so to speak. It will take a bit of coding but if you really want to not have an installer then it is an option. Another possibility is to use multiple textboxes and only have one visible but that would also require a lot of juggling and still have an upper limit.

Quote:

---

Originally Posted by Capp

All I need is a text field within the program to be able to hold more than a textbox can, or a suggestion as to how to accomplish that.

---

Capp

Some questions:

What is the source of the text in your TextBox?
-- user input
-- from a website
-- from a database
-- something else

Where is the contents of the TextBox to be saved?
-- a text fle
-- a database
-- something else

What is the purpose of the TextBox?
-- user only reads the text
-- user can create, read, edit the text
-- something else

As I was reading the thread, I hatched an idea, only to
find that AsmIscool beat me to the punch. Just to be
sure that he and I are talking about the same thing, let me
recast the concept:

-- use a text file as a temporary holder of text
-- populate the TextBox with the relevant portion (ie, small) of the text file

How you answer the above questions may enable us
to zero-in on a suitable work-around for you.

Spoo

[side]dilettante, how about side by side as a possible solution?[/side]

Quote:

---

Originally Posted by Capp

For this program, I need to avoid an installer if at all possible. That means not using any dependency files...

---

That's not going to happen. VB6 runtime files are dependencies as are the TLB and DLLs that VB uses. By dependency-free, you are making assumptions that those base dependencies already exist.

P.S. Using only system DLLs (i.e., user32, kernel32), you can create an API textbox (Edit window) which supports 2^32-1 characters. But that means you will have to subclass the textbox in order to interface with it.

SxS might be a solution depending on the operating systems you plan on deploying the app to.

To answer a few questions from above:

The text box is used for user input and output. The user will enter as much text as they want, whether through copy & paste or manually typing it in, then process it through the program and it is outputted in the same box. The box is cleared prior to output so that isn't one reason for the overflow.
The program encrypts the input text with various methods depending on what the user inputs. But large quantities of text yield high quantities of output and cause it to be truncated, thus causing crashes while processing the text. And vice versa, if the user has a large set of text to decrypt, if any of it gets shaved off, the decryption fails.

The text entered is not saved, printed or sent in any way. Once the program is closed, it is gone.

The idea of exporting it to a temporary text file occurred to me, but the final output still has to be completely within 1 text box. So, if it is saved to a text file and the total length is still larger than the textbox can hold, it will still not work.

Splitting the text into multiple boxes is not an option either as this causes all kinds of problems with the decrypting of said string.

I know that VB requires said system DLLS and runtime files to work. But, as of right this second, my program works with no support files on over 2 dozen different machines of various ages, configurations and operating systems. So, I want to keep it that way.

I don't know what SxS is and the operating systems will vary as this is not a custom app for a specific company.

Using the attached project example above may work, if I can get it to display properly within the program and allow the user to type and copy/paste text to and from it.
Doing it via API calls will work as long as the texbox is on the main form of the program and not a pop-up box as this will not work with the way the program is designed.

Thank you for all your help so far.

Quote:

---

Originally Posted by vb5prgrmr

dilettante, how about side by side as a possible solution?

---

I held back on suggesting such an approach for two reasons:

• The mention that Win2K might be a target platform.
• The OP's seeming unfamiliarity with setup/installer technologies.

On the second point I might be reading too much into the comments made. However I've found that packaging isolated applications can get very confusing for people. Usually the problems involve things like some of the vbAccelerator controls that seem to be missing something - or perhaps I'm missing something. ;)

So it's my failing. I just don't want to leave anyone hanging out there.

However the RichTextBox control isolates fairly well. For WinXP SP1 or later this could be an option that doesn't require any reprogramming effort.

BTW:

The example I posted has a silly bug. I'd never allowed it to run to completion so I didn't see it before.

In the Timer event handler there is a variable intCount that is As Integer yet as psoted I think I had it counting up to 65000 or something. Silly, I know.

Just declare it Long or lower the limit to something like 30000. It was just demonstrating shoving a lot of text into the RTB, so it's not critical to the point I was trying to show.

Capp

Let's overlook the size limit of the TextBox for the moment. I just
want to see if I understand your basic situation accurately.

Here are two hypothetical scenarios. Please correct me where I'm wrong:

1. New
-- user creates new text (by typing and cut/paste)
-- it gets encrypted
-- the encrypted text is saved to disk (or is "sent" somewhere else where it is used/saved)

2. Existing
-- user subsequently wants to edit/read an existing "file"
-- he "loads" the decrypted "file" into TextBox and modifies/reads it
-- it gets re-encrypted, or is destroyed
-- if the former, the re-encrypted text is saved to disk (or is "sent" somewhere else where it is used/saved)

Now to 65K-limit issue of TextBox.
Natch, the TextBox has MultiLine = True, and at least a vertical scrollbar.
Again, to my way of thinking, the following has a chance of working:

-- use a text file as a temporary holder of text
-- populate the TextBox with the relevant portion (ie, small) of the text file

1. New
-- User begins creating the text.
-- At 10K, for example, your app writes that segment to a temp TXT file.
-- It then repopulates the TextBox with only the last 2K of text.
-- User keeps going, process is repeated.
-- User is done, clicks "Submit" button, TXT file is encrypted, sent, locally destroyed

Issues:
-- Housekeeping: you'll need to keep track of what "segments" have been saved
-- Scrollbar: will "jump" around, which could be frustrating
-- Retracing: if user scrolls beyond current segment, momentary hiccup as TextBox is refreshed.

Sound promising?

Spoo

I'm not so sure about this.

Paged solutions can be pretty clunky. We really ought to have some good patterns for this for both textbox type things and grid controls. The problem comes up a lot when you deal with large files or databases that people need to see or work with.

Clearly it's an old story: There are lots of paging approaches in MS KB articles and many posted code examples. None of them are very neat though for something needed so often.

A nice, neat, general approach would probably be handy for all of us at some times. I've always felt something "double buffered" or even "triple buffered" would be handy to avoid the "jump" when you scroll past boundaries.


Honestly though, if the amount of text is small enough to work with in RTBs (under 2MB or so?) I'd personally use the isolated application (side-by-side manifest) approach. In this case you'd just have two files:

• EXE with embedded manifest.
• OCX, with its own embedded assembly manifest if the EXE manifest didn't have the OCX type-info in it.

Nothing to register. Could be packaged as a self-extracting archive to avoiding multifile downloading as needed.


As I said, I didn't want to get into this here though. People who avoid creating setup packages usually run into problems because they don't know what has to be, can be, and should never be packaged and distributed. Such knowledge is important no matter what type of packaging you use.

Their tales of woe can be seen in thread after thread in the Application Deployment forum here.

Alrighty,

For starters, I do know about creating and distributing installers. Have been doing it commercially for years. Just with this app, I am trying to avoid that as it is unnecessary for this type of app.

@Spoo
You misunderstood.

1) Yes, user types or pastes text into textbox. The program encrypts the text with whatever method they choose and displays the encrypted text into the same textbox. It is not saved, printed, exported to file/database or anything. The program has a button that will copy the textbox text into memory so the user can paste the text into whatever they want.

2) If the user is doing the reverse, they will paste the already encrypted text into the same textbox and decrypt the text as they see fit. Once agian, nothing is saved, sent or anything. They can then copy the decrypted text to clipboard if they want again, but nothing is saved.

Once the program is closed, the data in the text box, whether encrypted or not, is gone.


Once again, using an external text document as a place holder will not work for the very reason that, when they encrypt the text from within the text box, it all has to stay intact. So, if the program has to cut off part of the text to fit in the textbox, it will not encrypt/decrypt properly. So, yeah, if they had a million characters needing to be encrypted, it could be dumped into a notepad file for holding, but then it still would not be able to hold all the text in the textbox within the program. So, whatever is cut off would be left off when the text is copied, encrypted, decrypted, etc.. and any of those scenarios will cause it to crash, or error out anyway.

It has to all remain within the same area.
No user settings about the program are saved or stored anywhere on the computer. No files are created or destroyed.

@dilettante
I didn't let it finish either as it showed what I was needing.


This is the for example as to why I need this. This is what I did to crash it.

1) Pasted my entire resume' text to the program. ~1500 characters
2) Encrypted the text with with 5 passes and the converted the text to hex.
This jumped the size to over 64k characters.

So, since it cut off the rest of the text, when I decrypted the text using the same routine, it crashed because it was missing the rest of the text.

But, when I threw a RTB in there, it worked beautifully. I ran the same text against 3 different types of encryption with 5 passes each and converted to hex for a little over a million characters and it worked flawlessly. Except when I tried to run the program on the other computer, it crashed because of the missing or unregistered .OCX.
Change it back to the textbox control and it doesn't crash on runtime, but will not work as i showed above.

So, if I can use the API as you mentioned to create the richtextbox at runtime and not require including dependency files, that will be great. I just need to make sure I can completely specify the Top/Left/Width/Height/Name properties and include a vertical scroll bar.

Quote:

---

Originally Posted by Capp

So, if I can use the API as you mentioned to create the richtextbox at runtime and not require including dependency files, that will be great. I just need to make sure I can completely specify the Top/Left/Width/Height/Name properties and include a vertical scroll bar.

---

Name will be a problem, since the RichEdit control I was using goes "behind the back" of the normal way VB works with ActiveX controls. All you have is a window handle.

You might find that working with the RichEdit control wil be easier if you hook it up to Text Object Model (TOM) objects. The low-level interface I used in the example can get tedious to implement in VB.

This is not a RichTextBox control. You have to appreciate that the RTB uses the low-level interface to a RichEdit itself, and adds quite a bit of functionality to the resulting package. A bare RichEdit has none of the properties and methods of RTBs. I'm not even sure how you'd get a bare RichEdit control to allow the user to Tab to it to get focus.


If that's not important though, you might be able to create a bare RichEdit and site it on the Form as I did, then send it a messge to query it for its OLE interface.

Here is a clunky example that could stand improvement, but might be a start for you:

http://www.keyongtech.com/5007499-te...del-vb6-sample

Or perhaps what I gave you was enough aside from the message you must send to retrieve the RichEdit's contents?


To move text in and out in chunks of over 64K you need the EM_STREAMIN and EM_STREAMOUT messages I believe. These require callbacks.

A small solution that came into my mind ;)

See the file attached. Almost all lines are commented with the description. :)

Good luck...:thumb:

Quote:

---

Originally Posted by Capp

@Spoo
You misunderstood.

---

Capp

Yes, clearly I did.

I was merely trying devise a work-around using your given
restriction: only use a TextBox.

Thanks for your explanation, but sadly I still don't understand.
Forturnately you seem to have some other alternatives now, so at
this point I just remain curious:

What is the purpose of this app?
To merely test the encryption/decryption algos?

Spoo

The attached project example will cause problems because the user has to be able to type directly into the textbox, or paste from external source if they choose.

It looks more and more like I'm going to have to make an installer just to include this one dang file.

The reason I need to get this to work is because the program is finished. It is in a closed beta testing right now and only a small number of people got any kind of error when switching to a RTB instead of a regular textbox. Of course, once they downloaded the ocx file, everything worked fine.
Most of the workarounds provided so far will require me to completely change the functionality of the program. If I were just getting started, it wouldn't be a big deal, but as I said, it is "done" in most cases with the exception of the text length problem.

A thought....what are you guys opinion on, instead of having to do an entire installer just for this 1 dependency file, doing some good error trapping and having it recognize if this missing file is the problem and offer to download it from my server automatically?

My biggest concern with this is, the majority of the people using this won't be doing so as any kind of admin. So switching it to an installer package will require them to run it as admin, or in some cases, get their admin to install it for them.

All this for a dang textbox.

hmmm how about to get around it by checking the file if its there then start program if not download it into a certain location hidden or w.e from an internet server host of some sort, a free one would be effecient

those codes are on this forum in one of my older questions lol

Quote:

---

Originally Posted by Capp

... My biggest concern with this is, the majority of the people using this won't be doing so as any kind of admin. So switching it to an installer package will require them to run it as admin, or in some cases, get their admin to install it for them.

---

Not to beat a dead horse much more, but that is the point, no? If the user doesn't have permissions to install new software, as dictated by company policy or system administration, then they shouldn't be downloading and installing potentially dangerous software. I'm not suggesting your software is a trojan or spyware, but that possibility exists whether yours or some other author's software.

P.S. It's not your problem and shouldn't be a problem at all if policy allows it to be downloaded and installed.
I and others tend to be dinosaurs here... Build your app and play by the security rules. Trying to bypass those rules "generally" indicates malicious intent. My opinion of course.

Here's a possible solution. It's an example from allapi.net that I have modified slightly.

It starts notepad, which can hold a lot more text than a TextBox and puts it inside a Picturebox. It's not perfect, because the application window loses focus as soon as you click on the edit box, but it might work for you.

Add a Picturebox (Borderstyle to 0-None) and a Command button to the form. Start the app, type/paste some text into the edit box and click the Command button to retrieve the text.

Code:

---

Option Explicit

Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Private Declare Function MoveWindow Lib "user32" (ByVal hwnd As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal bRepaint As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As Long, ByVal lpWindowName As Long) As Long
Private Declare Function FindWindowEx Lib "user32" Alias "FindWindowExA" (ByVal hWnd1 As Long, ByVal hWnd2 As Long, ByVal lpsz1 As String, ByVal lpsz2 As String) As Long
Private Declare Function GetParent Lib "user32" (ByVal hwnd As Long) As Long
Private Declare Function SetParent Lib "user32" (ByVal hWndChild As Long, ByVal hWndNewParent As Long) As Long
Private Declare Function GetWindowThreadProcessId Lib "user32" (ByVal hwnd As Long, lpdwProcessId As Long) As Long
Private Declare Function GetWindow Lib "user32" (ByVal hwnd As Long, ByVal wCmd As Long) As Long
Private Declare Function LockWindowUpdate Lib "user32" (ByVal hwndLock As Long) As Long
Private Declare Function GetDesktopWindow Lib "user32" () As Long
Private Declare Function DestroyWindow Lib "user32" (ByVal hwnd As Long) As Long
Private Declare Function Putfocus Lib "user32" Alias "SetFocus" (ByVal hwnd As Long) As Long

Private Const WM_GETTEXT = &HD
Private Const WM_GETTEXTLENGTH As Long = &HE
Private Const GW_HWNDNEXT = 2

Private mWnd As Long
Private editboxhwnd As Long

Function InstanceToWnd(ByVal target_pid As Long) As Long
    Dim test_hwnd As Long, test_pid As Long, test_thread_id As Long
    'Find the first window
    test_hwnd = FindWindow(ByVal 0&, ByVal 0&)
    Do While test_hwnd <> 0
        'Check if the window isn't a child
        If GetParent(test_hwnd) = 0 Then
            'Get the window's thread
            test_thread_id = GetWindowThreadProcessId(test_hwnd, test_pid)
            If test_pid = target_pid Then
                InstanceToWnd = test_hwnd
                Exit Do
            End If
        End If
        'retrieve the next window
        test_hwnd = GetWindow(test_hwnd, GW_HWNDNEXT)
    Loop
End Function

Private Sub Command1_Click()

    MsgBox GetText(editboxhwnd)

End Sub

Private Sub Form_Load()
    'KPD-Team 1999
    'URL: http://www.allapi.net/
    'E-Mail: [email protected]
    Dim Pid As Long
    'Lock the window update
    LockWindowUpdate GetDesktopWindow
    'Execute notepad.Exe
    Pid = Shell("notepad.exe", vbNormalFocus)
    If Pid = 0 Then MsgBox "Error starting the app"
    'retrieve the handle of the window
    mWnd = InstanceToWnd(Pid)
    'Set the notepad's parent
    SetParent mWnd, Picture1.hwnd

    'Get the hwnd of notepad's edit box
    editboxhwnd = FindWindowEx(mWnd, 0&, "Edit", vbNullString)

    'Resize notepad to only show the edit box. Might want to play around with these numbers.
    MoveWindow mWnd, -4, -50, (Picture1.ScaleWidth / 15) + 8, Picture1.ScaleHeight / 15 + 77, 0

    'Put the focus on notepad
    Putfocus mWnd
    'Unlock windowupdate
    LockWindowUpdate False
End Sub

Private Sub Form_Unload(Cancel As Integer)
    'Unload notepad
    DestroyWindow mWnd
End Sub

Public Function GetText(hwnd As Long) As String
    Dim strTemp As String
    Dim lngLength As Long

    lngLength = SendMessage(hwnd, WM_GETTEXTLENGTH, ByVal 0, ByVal 0)

    strTemp = Space(lngLength)

    SendMessage hwnd, WM_GETTEXT, ByVal lngLength + 1, ByVal strTemp

    GetText = strTemp
End Function

---

The biggest reason to restrict admin rights isn't to keep people from running oddball applications but to protect the system folders, registry, and other applications from corruption by poorly put together installation packages. Secondary after that is probably to defeat as much malware as possible, especially trojan horses, spam zombies, and the like.


If you packaged this as an isolated application you can avoid most of these issues. Your application and its depedencies can be "XCopy" deployed, i.e. the application folder and any subfolders and files can just be copied to any read/write user location and run from there. Richtx32.ocx does not need to be registered for use in Windows XP SP1 or later if you have provided the proper isolation manifests.

This is what vb5prgrmr was getting at way back in post #13.

You can also repackage an isolated application as an MSI file marked for unelevated per-user intstallation. Beginning in Windows 7 there is even a special folder location for such installations, an alternative to %SystemDrive%\Programs (used to be called "Program Files" back in ancient times). You can use this location in XP or Vista as well. It's %LocalAppData%\Programs. Some of this is covered in Authoring a single package for Per-User or Per-Machine Installation context in Windows 7.